Bill Roper's Journal

I have been head down in bugs for the last two days since I came back from Confusion, dealing with nasty interactions between MFC in C++ and interoperable code in Java. I think that I've managed to sort out the nastiness, although it was disconcerting to find a big fat bug in a built-in Windows method.

*sigh*

One of the nice things about MFC's serialization routines is that if you write your code correctly, you should be able to take a file that was written out by a 32-bit application and successfully read it into a 64-bit version of the same application. The trick is not doing things that will cause the serialization code to break as you move between the 32-bit and 64-bit compilers.

Enter CMap. CMap is a lovely little template class that allows you to take a key of arbitrary type and locate a value of some other arbitrary type. You can even serialize your CMap objects out to your archive and read them back in.

The problem occurs when you're trying to read and write a complex type, like an MFC class, as either your key or your value. CMap uses the SerializeElements function in order to persist the keys and values and -- by default! -- writes an exact copy of the bits that existed in your object to the archive.

This is almost certainly not what you wanted to happen if your key or value is an MFC class, especially if it contains any virtual functions -- which it will, if you derived it from CObject, or any pointers. See, one of the things that's hidden inside your class is a pointer to the virtual function table for the class. I cannot imagine any good outcomes from reading in a previously stored value of that pointer.

But perhaps you're fortunate and don't actually call any of the virtual functions that you might try to find via that pointer. You're still going to get clobbered when you try to move between a 32-bit and a 64-bit version of your application, because the pointer that had been four bytes long is now eight bytes long and when the default implementation of SerializeElements takes the sizeof( YourClass), you get a different value on the two systems. Hilarity -- and a CArchiveException -- ensues.

The happy news is that you can easily write a templated version of SerializeElements that will call CArchive::SerializeClass() to write out the class header for your key and/or value followed by a call to serialize the underlying object. Or if your CMap stores a pointer to your key or value class, you can use the insertion/extraction operators, which is even simpler. And then your CMap classes will serialize correctly whether you're on a 32-bit or a 64-bit system.

Isn't that easy?

MFC does not have wonderful support for changing languages on the fly in a running application by reloading the underlying resource DLL. It turns out that this is something you can do -- you just have to get your incantations straight.
( Technogeekery inside... )