Nevertheless, it's just one sentence you need to understand carefully. Reading several books and searching for different explanations is not going to help much. I'm just saying it might help to just zero in on the explanation at hand and try to understand it very carefully.yungman said:
I think that it might be helpful to @yungman if he were to read and carefully think over this: https://www.fluentcpp.com/2017/03/31/how-typed-cpp-is-and-why-it-matters/Jarvis323 said:
Maybe it wouldn't kill them, but the extra words make the explanation incorrect. <datatype> could be a float, for example.yungman said:
+1Jarvis323 said:
The last code you posted was in post #24. That code couldn't have produced this output. Also, if you write to a binary file, to see what's in it, you need to use a binary file viewer. You can't just use "cout << ...".yungman said:BTW, I tried your suggestion of &Iw[index] instead Iw[index] in post 24. This is what is written in the file:
Iw[] = {1,2,3,4,5};
ofstream outF;
ifstream inF;
outF.open("data.txt", 51);
outF << Cw;
outF.close();
inF.open("data.txt", 51); //outF.close();
//inF >> Cr;
inF.getline(Cr, 51);
cout << " read from file into Cr: " << Cr << "\n\n";
inF.close();If you don't have a breakpoint set, VS will run the program and exit the debugger.yungman said:
F9 toggles a breakpoint - Use F10 to single-step through a program.yungman said:
Things work the same in C# or C++.yungman said:
Please do this before making any new posts.yungman said:
Is this from one of the books you've been reading? If so, using a "magic number", 51, for the open mode is very bad style. It took me about 20 minutes to find the definitions of the flag values that make up 51. When you open the input stream, inF, you are opening it in binary and input modes (which is good), but you are also opening it in truncate mode, so the contents are getting erased immediately before the call to getline(). This means that the output statement at the end will not display anything for the char array or string.yungman said:
I made one small change in your code, and it worked just fine, so either you were looking at the wrong thing as the cause of what you were seeing, or I don't understand what you're asking.yungman said:
inF.open("data.txt", std::ios::in | std::ios::binary);#include <iostream>
#include <fstream>
using namespace std;
int main()
{
fstream dataFile1, dataFile2;
dataFile1.open("demofile1.txt", ios::binary|ios::out);
dataFile2.open("demofile2.txt", ios::out);
unsigned x = 0xDEADBEEF;
dataFile1.write((char *)(&x), sizeof(x));
dataFile2 << x;
dataFile1.close();
dataFile2.close();
}I am so sorry!Mark44 said:
Does your computer have function keys? I looked at one of the HP laptops on their site, and they have a row of what they call action keys along the top. The picture I saw wasn't very clear, but it looks like these keys have something else written on them, like f1, f2, and so on. Possibly they work by pressing the fn key at the lower left. Or maybe you have to disable the action key feature.yungman said:
If you go to https://support.hp.com/ there is a form to enter the serial number which will be on a label on the underside of your laptop. This will identify it unambiguously.yungman said:
That sounds about right, the option to change the keys default mode should be fairly easy to find.yungman said:
Debug menu --> Windows --> Localsyungman said:
In my view that's good. The 'diagnostic techniques' set of topics constitute an eventually-advanced topic set that pretty much begins with step-by-step analysis. I recommend that you please continue with your use of the debugger tool-set.yungman said:
Most of the I/O routines return a value or have a way to check whether they succeeded. In the code that I showed in post #46, I added a line to see if the file opened successfully.yungman said:
dataFile1.open("demofile1.txt", ios::binary|ios::out);
if (dataFile1.fail()) std::cout << "Failed to open demofile1.txt" << "\n";dataFile1.write((char *)(&x), sizeof(x));
if (!dataFile1) std::cout << "Failed to write to demofile2.txt" << "\n";+1sysprog said:
Yes. The bit pattern that represents an address doesn't change in the slightest. All that changes is that the address is now considered to be the address of a char instead of an int.yungman said:
No, not quite. The left side of what you wrote is wrong.yungman said:
int x = 0x1234; // Declaration + initialization of x
pInt = &x; // pInt holds the address or x
char * pChar; // Declaration --pChar can hold the address of a character.
// Since pChar isn't initialized, it contains only a garbage value.
pChar = reinterpret_cast<char *>(pInt); // The address in pInt is copied to pChar