Click here to Skip to main content
15,868,016 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Just this one boolean. Not a general question. A general guide would be helpful for later, but I am specifically wanting this one at this time.

I have tried initializing it, but I am not certain if that is necessary or if it might cause problems. The code works, but I want more understanding of it.

Thank you.

What I have tried:

HANDLE hDFile = CreateFile(L"utf8_UsingByteOrderMark_C_天堂.txt", GENERIC_READ | GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);

DWORD NumberOfBytesWritten;

BOOL bErr = 0;      // Does this need to be initialized?
unsigned char BOM[3]{ 0xef, 0xbb, 0xbf };

bErr = WriteFile(hFile, (LPCVOID)BOM, (DWORD)sizeof(BOM), &dwBytesWritten, NULL);

bErr = WriteFile(hDFile, L"hello - J - こんにちは - abcdefghijklmnopqrstuvwxyz", 90, &NumberOfBytesWritten, NULL);

CloseHandle(hDFile);
Posted
Updated 29-Jun-22 12:01pm

Quote:
Does this one boolean need to be, or should it be initialized?

This specific Boolean do not need to be initialized because its value is never used in this code.
This code does exactly the same:
C++
HANDLE hDFile = CreateFile(L"utf8_UsingByteOrderMark_C_天堂.txt", GENERIC_READ | GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);

DWORD NumberOfBytesWritten;

BOOL bErr = 0;      // Does this need to be initialized?
unsigned char BOM[3]{ 0xef, 0xbb, 0xbf };

bErr = WriteFile(hFile, (LPCVOID)BOM, (DWORD)sizeof(BOM), &dwBytesWritten, NULL);

bErr = WriteFile(hDFile, L"hello - J - こんにちは - abcdefghijklmnopqrstuvwxyz", 90, &NumberOfBytesWritten, NULL);

CloseHandle(hDFile);

The correct principle is:
C++
// declare the variable
BOOL bErr;

// Store a value in variable
bErr = 0;
// or
bErr = WriteFile(hFile, (LPCVOID)BOM, (DWORD)sizeof(BOM), &dwBytesWritten, NULL);
// use the variable
if (bErr) ...

No exeption, unless making decisions based on razndom values is not a problem.
 
Share this answer
 
Comments
merano99 29-Jun-22 17:47pm    
You're right when you say that error handling is still completely missing. Even system calls should check by checking the return values. For the sake of clarity, the test in forums is often initially omitted. When debugging, however, they often do a good job. (5+)
Patrice T 29-Jun-22 19:08pm    
Thank you.
CPallini 30-Jun-22 2:45am    
5.
Patrice T 30-Jun-22 3:33am    
thank you
Return values ​​do not have to be initialized (for the compiler). But it's not a mistake if you do it. It might help when debugging if all variables have defined values. As Patrice has already written, return values ​​should also be checked if possible, that's what they are there for.

For the sake of clarity, error handling in forums is often left out at first. However, they often do a good job when debugging. Error handling should always take place directly after a system call to avoid subsequent errors.

It is important to declare all data types correctly. Under C++ you can leave this to the compiler with the keyword auto.

In this case, the Windows system call Writefile() results in a BOOL that is initialized with FALSE or TRUE. FALSE always corresponds to a 0 (data type int).
BOOL is not compatible with the C++ data type bool!
 
Share this answer
 
v3
Comments
Patrice T 29-Jun-22 19:09pm    
+5
merano99 29-Jun-22 19:41pm    
Thanks
bErr doesn't need to be initialized, because it's never used until it stores the result from WriteFile.

But if you want to initialize it, initialize it to false, not 0.

Unless you disable compiler warnings, the compiler will tell you if you're using something that hasn't been initialized.

When unsure, it's good practice to initialize. There's no harm in doing so.

In more modern C++, you could just remove the line that declares bErr and write
C++
auto bErr = WriteFile(...);
 
Share this answer
 
Comments
Member 15078716 29-Jun-22 15:15pm    
Thank you.

I do not like auto because it is less direct. The compiler makes a guess as to what bErr is and I prefer to know what I am sending and getting on both sides of the = sign.

But, your answer is helpful and complete. Thank you.
Greg Utas 29-Jun-22 15:57pm    
I love auto, and eventually you will too. The compiler never has a problem guessing the correct type, but you have to be explicit when you want a reference:
const string& f();auto str = f();
and str copies the string, which is more expensive than saving the reference. To save the reference, you have to write auto& str....
Member 15078716 30-Jun-22 13:52pm    
I use auto when I have to.

It does come in handly when I am struggling to grasp what is the correct type and at the same time understand why that type should be the one that I use. If I put in auto, then I can mouse over the code and get what the compiler has guessed is the most correct. Then I can hard code that type in so that later, when reading the code, I can see the type instead of it being hidden behind the word auto.

I agree that auto has it's uses. I just do not like it's hiding the type from me in a quick read of the code.

Greg Utas 30-Jun-22 14:40pm    
I like auto because it saves typing (especially when template iterators are involved) and it keeps lines under 80 characters, which is what I prefer. But it sounds like you're new to C++, so what you're doing makes a lot of sense.
merano99 29-Jun-22 17:40pm    
For system calls like Write File(), I recommend using exactly the variable types that are intended for here. A C++ data type does not fit here!

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900