"Robert Ramey" <ramey@rrsd.com> 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#nonintrusiveversio...): 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