Re: [boost] serializatation const change (was Re: Problem withserialization mersenne_twister with cvs)

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2005-05-28 13:56:25

----- Mensaje original -----
De: Jeff Garland <jeff_at_[hidden]>
Fecha: Sábado, Mayo 28, 2005 8:06 pm
Asunto: Re: [boost] serializatation const change (was Re: Problem 
withserialization mersenne_twister with cvs)

> On Sat, 28 May 2005 10:05:15 -0700, Robert Ramey wrote
[...]
> > I don't see this change as "breaking code" but rather detecting 
> code 
> > that is very likely already broken.
> >
> > So, as I said, its not that I'm unsympathetic to your point of 
> view, 
> > I just don't think everyone is sympathetic to mine.
> 
> Well, I'd say that 'no one' is sympathetic to yours, yet ;-)  I 
> don't think
> that Vladimir, myself, or the others that have posted on this 
> topic are
> convinced that this change is really going to prevent people from 
> making the
> error you are concerned about.

For the record, not that I'm in love with the stricter
const rules either, but I must confess that, when hit
by them the first time, they actually uncovered a (potential)
problem in my test code. So...

I've been thinking about this issue, and my impression is
that regular code won't be hit as much as one might think.
Typically, serialization is used like this in a program:

class my_class
{
  // add serialziation capabilities
};

void save(const my class&)
{
  // some file-opening work prior to actual saving
 ...
}

void load(my_class&)
{
  // some file-opening work prior to actual loading
 ...
}

A typical program will have a centralized point of usage
of serialization, and the usual const-abiding rules
won't collide with Boost.Serialization. Now, a test
program like the ones we've been writing to check the
serialization capabilities of our libs is more likely
to follow this pattern:

std::ofstream ofs(..);
archive::text_oarchive oa(ofs);

my_class_1 c1;
...
my_class_n cn;

...

oa<<c1;
...
oa<<cn;

std::ifstream ifs(..);
archive::text_iarchive ia(ofs);

my_class_1 cc1;
...
my_class_n ccn;

...

ia>>cc1;
...
ia>>ccn;

BOOST_CHECK(c1==cc1);
...
BOOST_CHECK(cn==ccn);

and here we *do* run into the const problem.
The key difference is that, in the latter pattern of
usage, we are creating local classes just to check
whether they're properly archived and restored.
In a real program, the serialization code is typically
provided a class to archive from the outside, as
serializating classes created on the fly doesn't make
much sense after all.
Get my point? So, to sum it up, although I think
stricter const rules won't prevent as many
problems as desired, I think most users won't notice
anyway. We lib testers belong to a different flock.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo