Yeah it is a little confusing, but you can override the Serialize() function
Tom Serface wrote:
If you're just going to read and write it look at CArchive. It will
allow
you to write out the array and if you are using MFC object it will even
identify them automatically.
http://msdn2.microsoft.com/en-us/library/caz3zy5s.aspx
Tom
Thank you very much for your early reply. Yes, I'm using CObject as a
base class for my objects. I have read everything I've found on MSDN
about serializing, but I still don't understand it well. It seems that
I forgot to
make clear the most important point:
The document I want to serialize contains a list of objects, where
each object is of one of these derived CFoo_X classes but is
referenced by a (polymorphic) pointer to the base class, like this:
CTypedPtrList<CObList,CFoo*> m_listElements;
Now, each of the elements in the list can be of ANY of the classes
derived from CFoo (which is an abstract class derived from CObject).
And some of these classes have an array as a member. These are
my thoughts (hopefully wrong):
1- If I want to call each object's serialize() function, then at the
time
of deserializing (loading) I'll need to know the exact class of each
object *before* I create it and then call its serialize() function.
2- If instead I use the overloaded << and >> operators to store/load
each element, thenI don't know what will happen when I try to store
an object that has an array as a member. Will the program automagi-
cally store the array? Or will it store the value of the pointer to it,
which will be garbage when loaded?
So, to my very limited knowledge, I would need to go through the
CTypedPtrList, calling each element's serialize() function, which
will first store a string as an identifier and then its own data. Thus,
when loading from file, I would have to retrieve the string and create
the corresponding object, and then call its serialize() function for it
to load itself from file. I hope there is a better alternative than
this.