Re: [boost] [serialization] const-correctness

From: David Abrahams (dave_at_[hidden])
Date: 2006-03-13 02:15:58

"Robert Ramey" <ramey_at_[hidden]> writes:

> David Abrahams wrote:
>> In giving a presentation about the serialization library on Tuesday
>> the students got very hung up on the const-correctness of output
>> streaming using the usual single serialize(MyClass&, ... ) function.
>
> I'm not sure I get this.  I don't see any serialize functions or templates
> that look like that.  Free functions look like
>
> template<class Archive, class T>
> serialize(Archive &ar, T & t, ..

Not unless there's only one type in a namespace that needs
serialization.  In general, T above is replaced with some concrete
class type and is not a template parameter
(http://www.boost.org/libs/serialization/doc/tutorial.html#nonintrusiveversion):

  template<class Archive>
  void serialize(Archive & ar, gps_position & g, const unsigned int version)
  {
      ar & g.degrees;
      ar & g.minutes;
      ar & g.seconds;
  }

If there is only one serializable type in a namespace, you can write
the version you showed above with the template parameter T, and T can
be deduced to be X const for some X.  But that still doesn't supply
much assurance because although the X will very commonly be non-const
even for "out" serialization, the programmer would like to be sure
he's not applying any mutating operations to it.

> while member functions look like
>
> template<class Archive>
> void serialize(Archive &ar, const unsigned int version){
>     ...
> }

Exactly.  Note no trailing const on the signature.

>> Can you serialize const objects that way?  

Can you?  I'd really like to know.

>> Does the library cast away const?
>
> The library can't cast away const because remove_const wasn't available
> for msvc 6.0.

You don't need remove_const for that in general; you can deduce T from
T const inside a function template.

> ar << t;  // forces t to be const - for now

Forces how?  Do you mean it won't compile if t is non-const?

If so, I think that's backwards.  Nobody cares whether t is const;
they care that serialization functions don't invoke anything that
could modify t when serializing "out" as in the case above.

> ar >> t; // prohbits t from being const

Of course.

> ar & t;  // a couple layers down adds const if its a saving archive.

Adds const to what?

> I'm not sure if the following refers to the questions raised in your
> course, but I can make the following comment.
>
> I suppose if one were clever enough, he might enforce the current
> const rules with the & operator as well as the << and >> operators
> depending on the archive type.  It would certainly be more consistent
> than the current scheme.  I don't know if it would be possible to do
> this, but given that this const checking has been the source of a few
> vociferous complaints its not totally clear that it won't be removed
> in the future.  So I'm not all that motivated to invest time to investigate
> this.  Also, the current system provides and "escape hatch" for those
> who object to the const rules.

I don't think my students knew about the const rules to which you're
referring, although they may well have been very upset had they known.
In fact, I only now distantly remember that you have some rules about
constness that I didn't like much.  But that's beside the point,
because I'm not talking about restrictions you impose, but rather,
useful restrictions that are missing.

>> One could get the compiler to deduce constness appropriately if the
>> object being serialized were specified as:
>>
>>   template<class Archive, class GPSPosition>
>>   void serialize(Archive & ar, GPSPosition& g, const unsigned int
>> version)
>
> I don't see how this is different from the above (replacing
> GPSPosition with T)

It isn't different.  Unfortunately, as I've said, that isn't the way
one normally operates with this library, and it provides little
assurance that no mutating operations are performed on serialized
objects when they're being written to an archive.

>> but of course that doesn't overload very well; you'd need some other
>> way to indicatethe type of the object to be serialized.
>>
>> How is this all related to
>> http://www.boost.org/libs/serialization/doc/index.html?
>
> ????

Sorry, I meant
http://www.boost.org/libs/serialization/doc/rationale.html#trap

Darn menus.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com