[serialization] const-correctness

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[serialization] const-correctness

David Abrahams

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.
Can you serialize const objects that way?  Does the library cast away
const?

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)

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?

(and there are some weird glyphs showing up at the top of the menu at
http://www.boost.org/libs/serialization/doc/index.html for me:

  

that's a lowercase 'i' with diaresis, a spanish right double quote
character (looks like >>) and an inverted question mark.)

Thanks in advance,
Dave

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [serialization] const-correctness

Ben Artin
In article <[hidden email]>,
 David Abrahams <[hidden email]> wrote:

> (and there are some weird glyphs showing up at the top of the menu at
> http://www.boost.org/libs/serialization/doc/index.html for me:
>
>   
>
> that's a lowercase 'i' with diaresis, a spanish right double quote
> character (looks like >>) and an inverted question mark.)

They are the UTF-8 BOM. <http://www.w3.org/International/questions/qa-utf8-bom>.
I am pretty sure that this is wrong, because the page's META tag claims it's in
iso-8859-1.

Ben

--
I changed my name: <http://periodic-kingdom.org/People/NameChange.php>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [serialization] const-correctness

Robert Ramey
In reply to this post by David Abrahams
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, ..

while member functions look like

template<class Archive>
void serialize(Archive &ar, const unsigned int version){
    ...
}

> Can you serialize const objects that way?  Does the library cast away
> const?

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

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

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

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

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.

> 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)

> 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?

????

Robert Ramey



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [serialization] const-correctness

David Abrahams
"Robert Ramey" <[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost