29.4 Serializing an array of pointers

The most important part about the Pop Framework's serialization code is one single line in the cGame::Serialize method:

 _pbiota->Serialize(ar); 

Getting that line to work was quite a task. Why? The _pbiota object is a CTypedPtrArray<CObArray, cCritter*> of pointers, some of which point to cCritter objects and some of which point to objects of child class types such as cCritterBullet , cCritterArmed , cCritterArmedPlayer , and the like. The array template type CTypedPtrArray<CObArray, cCritter*> is defined by MFC as an alternative to the simpler template type CArray<cCritter*, cCritter*> .

First of all, we need to tell the cCritter class and its subclasses how to write and read their data; we do that by implementing Serialize for the class and the subclasses.

Second of all, we need to arrange things so that we save and read the contents of the _pbiota array objects and not the values of the pointer addresses . This will happen partly because we used the DECLARE_SERIAL and IMPLEMENT_SERIAL macros and partly because we are using a CTypedPtrArray<CObArray, cCritter*> array rather than a vanilla CArray<cCritter*, cCritter*> .

Third of all, _pbiota is a polymorphic array of pointers, some of which are cCritter* pointers and some of which are various child critter class object pointers, so we need some way to tell which is which when we are writing and reading their data. This, again, is taken care of by the fact that we used the SERIAL macros and the fact that we used the special complicated kind of CArray template CTypedPtrArray<CObArray, cCritter*> instead of the simpler CArray<cCritter*, cCritter*> .

It turns out that the default behavior of a standard CArray is in fact the wrong thing for arrays of pointers: it block copies whatever data is in the array. That is, it writes some information that you totally don't care about: the numerical values of the addresses where your data objects live. What you want to write is the data that lives in the objects. There are three ways of avoiding the inappropriate serialization behavior of CArray .

Serializing a CTypedPtrArray of CObject pointers

This is the most modern approach, the one we use in Pop Framework. If your class inherits from CObject , you can use a special kind of CTypedPtrArray instead of a CArray .

 CTypedPtrArray<CObArray, cCritter*> *_pbiota; 

(To be accurate we must immediately mention that _pbiota is actually a cBiota * object; the cBiota class is a child of the class CTypedPtrArray<CObArray, cCritter*> .) The virtue of using the CTypedPtrArray is that a CTypedPtrArray ' knows ' it's made of pointers so it will serialize your pointers by calling the proper kind of operator>> or operator<< for each pointer. This technique will not work if you use the CTypedPtrArray<CPtrArray, cCritter*> *_pbiota , in fact if you use an array like this, your serialization won't work at all.

The first modifying argument to a CTypedPtrArray definition can be either CPtrArray or CObArray . It's the second option that we must use here. The CObArray tells the CTypedPtrArray it is made of pointers to serializable CObjects . The effect of the first argument is to make CTypedPtrArray<CObArray, cCritter*> in fact be a special kind of CObArray .

[It would be more logical if the modifying argument used to specify the kind of CTypedPtrArray were CObPtrArray , and not CObArray , but, as we've said before, if MFC were fully consistent and logical, it wouldn't be true Windows programming! (Not that any other kinds of programming are perfectly logical either.)]

If you set a breakpoint at the line _pbiota.Serialize(ar) and step though a save or load in the debugger we find that the following MFC method gets called down in an MFC source-code file called Array_O.cpp. (In order to be able to step into MFC source code, you need to have set the options to install the source code when you installed Visual Studio.)

 void CObArray::Serialize(CArchive& ar)  {      if (ar.IsStoring())      {          ar.WriteCount(m_nSize);          for (int i = 0; i < m_nSize; i++)              ar << m_pData[i];      }      else      {          DWORD nOldSize = ar.ReadCount();          SetSize(nOldSize);          for (int i = 0; i < m_nSize; i++)              ar >> m_pData[i];      }  } 

In looking at this code, understand that any kind of CArray , CObArray , or CTypedPtr array has two main private fields: its m_nSize that gives its size, and its m_pData that gives its array of elements. In the case of an array of cCritter* pointers, m_pData will have the type cCritter** .

As we described in the last subsection, we have a special overloaded pointer-based extraction operator<< and the special overloaded pointer-based operator>> to read the pointers intelligently. Rather than copying the address values of the pointers, the CObArray calls call these special overloaded extraction and insertion operators.

It's worth repeating that we don't explicitly define operator<<(CArchive &, const cCritter*) and operator>>(CArchive &, cCritter *&) . These are implicitly defined by (a) making cCritter a child of cObject , (b) putting the DECLARE_SERIAL and IMPLEMMENT_SERIAL macros in, respectively, critter.h and Critter.cpp , and (c) prototyping and implementing a cCritter::Serialize(CArchive &ar) method.

Serializing a CArray of CObject pointers by overloading ::SerializeElements

The second approach is to stick to the more familiar approach of defining CArray<cCritter*, cCritter*> _critters . The problem here will be, as mentioned above, that the default CArray::Serialize method will block copy the pointer addresses. So here we need override a certain global polymorphic the SerializeElements function. We would add some code like this to our Popdoc.cpp file.

 void AFXAPI SerializeElements(CArchive &ar, cCritter **pcritterarray,      int count)  {      int i;      if (ar.IsStoring())          for (i=0; i<count; i++)              ar << pcritterarray[i];                  // Uses operator<<(CArchive &, const c*)      else          for (i=0; i<count; i++)              ar >> pcritterarray[i];                  //Uses operator>>(CArchive &, cCritter *&)  } 

Note the peculiar prototype for the SerializeElements global function. Another tricky point here is that the linker will complain if you define this function in critter.h or Critter.cpp . Your override of SerializeElements has to be defined inside the document implementation file Popdoc.cpp. A good place to keep it is right before your override of the CDocument::Serialize function. You may be tempted to skip writing this odd little bit of code when using a standard CArray of pointers, but if you leave it out, then when you try and read in a file, your program will crash because you will read garbage values into your pointers.

Serializing a pointer array the hard way

We said there were three approaches, so what's the third? The third is to pigheadedly do it all yourself and not even derive cCritter from CObject . The price would be that we then need to keep a CString _classname field inside our cCritter and class to take the place of the CRuntimeClass information. It's enough to just have _classname be either cCritter or cCritterBullet or whatever. Note, by the way, that any child of the CObject class has a CRuntimeClass member, and one of the fields of CRuntimeClass is in fact a CString that holds the name of the class. So if you do this by hand, you're only copying what the MFC framework wants to do for you automatically.

The trick for serializing an object this third way would be to save off the name string before saving the object, and when you are reading it back in, you read in the name string and have a switch statement to construct the right kind of critter child class object pointer to read the object into. But there's no reason to work this hard. Save your energy for something other than reinventing the CRuntimeClass !