Change in behavior of CArchive::operator << (bool b)

Question

5.00/5 (1 vote)

See more:

Does anybody know the version of MFC when the behavior of CArhive::operator << (bool b) changed from casting bool to LONG (MFC 6) to casting it to BYTE (MFC 9 and up)?

This is a big deal, since if you don't get it right, the difference in size of LONG and BYTE will completly wreck the serialization of files stored/loaded under different conventions. I want to make the files _MFC_VER aware and use the convention (4 or 1 bytes) as appropriate to the individual file, but I need to know just when the convention changed, and right now, I can't narrow it down any more than that it happened somewhere between Studio 6 and Studio 9. Sadly, neither Google or a scan of Code Project has yielded any answers.

Thanks,

Michael Waters

Posted 25-Oct-10 7:55am

Michael Waters

Add a Solution

2 solutions

Solution 3

I would suggest that instead of making it _MFC_VER aware, you'd be well advised to store your own archive version number in each archive. That way, future updates to the file structure can be handled without regard to MFC version or any other compiler-based variable.

Posted 26-Oct-10 0:47am

krmed

Comments

Michael Waters 26-Oct-10 11:40am

We already store an individual object archive number, but I want to add the _WIN_VER dependency to cover all the bases, since we have multiple users with multiple versions of the application floating around out there, and thse are mission critical data files. Sure, we can tell all of our users to upgrade to the latest build of the software, but experience has shown us that users don't always listen to us.

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

Nish Nishant · Accepted Answer · 2010-10-25T08:08:00

Solution 1

This has been so since VC++ 2003. Boolean values are now of type bool instead of BOOL.

And the intrinsic bool is 1 byte in length. So if you want the old behavior do not use bool member fields or locals, and instead use BOOL (which will still work as you expect it to).

Posted 25-Oct-10 8:08am

Nish Nishant

Updated 25-Oct-10 8:11am

v3

Comments

Michael Waters 26-Oct-10 11:32am

Wow, that was fast! I love Code Project. Thanks for the help.

So the change occurred between _MFC_VER 0x0700 and _MFC_VER 0x0710. The problem lies in that the files store a mixture of both BOOL (code dating from before bool was part of the C++ standard) AND bool values. I'm trying to migrate it all to use bool only, but it's a slow process as we finally transition from Studio 6 to Studio 10.