Re: How to serialize Mfc template dialog class ?

From:

Goran <goran.pusic@gmail.com>

Newsgroups:

microsoft.public.vc.mfc

Date:

Sat, 5 Sep 2009 03:19:29 -0700 (PDT)

Message-ID:

<ebd67116-9902-47ac-9c5e-b3625d746c4b@o41g2000yqb.googlegroups.com>

OK, so I'll share my experience and how we do it overall. It is about
a run-off-the mill editor-type application that gets developed over
the course of a decade (and counting). I am not the original author
(Hi, Serge!), but I see no major problems serialization-wise.
Certainly there are things that could have been done better, but hey,
rarely do I think that my own code is good when looking at it a couple
of years, either! ;-)

What we do is provide only backwards compatibility. That decision
serves us well, I'd say. We use VERSIONABLE_SCHEMA for particular
classes and also have global document version number. Canonical
Serialize is:

void CFoo::Serialize(ar)
{
  //storing:
  ar << member1 << m2 << m3 << ...;

  //loading:
  ar << member1<<m2;
  if (schema >= 2)
  {
    ar << m3;
    if (schema >= 3)
    {
      ar << m4;
      // etc
    }
  }
}

For one particular class, I don't think we ever went over 20 or so.
Clearly, that "if" nesting in loading branch can certainly become
deep, but I don't remember that we tried to alleviate by moving code
(e.g. ReadFromSchema3(ar)). Frankly, I think it's rather canonical and
not complicated at all.

About global document format number: each set of particular changes,
before going into the wild, requires a bump in this number. That way,
code knows whether it's too old to read a particular file (newer).
Older files it must read anyhow.

Sometimes (that is very rare, though), we remove something from the
program. For that, we just do ar << unused and ar >> unused. So no
schema change for that. Sometimes we change data type of a particular
variable. That is handled by either "unused" trick, either specific
schema check "in the middle". But that is rare, too.

I'd say, when the above is followed strictly, serialization really is
a breeze!

Now, of course, this is only overall approach, and things indeed do
get messy in places (I'd prefer not to talk about them ;-) ).

A pet peeve of Serialization for many must be the inability to have
schema number on a per-derived-class basis. That is, schema change
anywhere in a hierarchy demands schema change for all participating
classes, so that they all carry the same schema number. Go MS, huh?
Recently, someone here complained that he could not rename a class
because of serialization. Yes, that is a breaking change, but not
insurmountable, either (I don't think we ever did this, BTW!)

Goran.