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?