Re:[boost] Re: Serialization Formal Review #2

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-04-25 23:23:44

Message: 11
Andreas Huber wrote:

> 1. On compilers supporting ADL, it seems the user-supplied serialization
> function for non-intrusive serialization

> template<class Archive>
> void serialize(Archive & ar, gps_position & g, const unsigned int
> version);

> could also be put into the namespace of the type that it serializes. If
> this is correct it should be mentioned in the tutorial & reference. If
> not, there should be a rationale why not.

I did try this in my environment VC 7.1 and it failed to work.  Does anyone
want to assert that it should or shouldn't work?

> 2. save/load naming:
All functions that have to do with reading from an archive are named load*,
> all functions that have to do with writing to an archive are named save*.
> To me (non-native speaker) these names are generally associated with
> persistence only. Since the library is more general (one could use it for
> network communication, etc.) load/save are a bit missleading. I'd rather
> see read/write or other names that more clearly communicate what the
> functions are doing.

I used save/load consistently specifically to distinguish from read/write
which seemed to me too suggestive of persistence, files and streams.

> 3. archive naming:
> The word archive also seems to be associated with persistence. I think
> serializer would much better describe the functionality. Another option I
> could live with is serialization_stream (I slightly disagree with the
> assertion in archives.html that an archive as modelled by this library is
> not a stream. It might not be what C++ folks traditionally understand a
> stream is but to me it definitely is a more general stream, i.e. a stream
> of objects/things/whatever).

Archive is perhaps a little too suggestive. I borrowed from MFC.  Making
changes would have a huge ripple effect through code, file names, namepace
names and documentation. I don't find any proposals for alternate naming
sufficiently compelling to justify this.

> 4. Object tracking 1: Seeming contradiction
> I've had difficulty determining how exactly object tracking works. I
> believe the associated docs are slightly contradictory:

> - Under exceptions.html#pointer_conflict I read that the pointer_conflict
> exception is thrown when we save a class member through a pointer first
> and then "normally" (i.e. through a reference).

Correct.

> - traits.html#tracking says "... That is[,] addresses of serialized
> objects are tracked if and only if an object of the same type is anywhere
> in the program serialized through a pointer."

Correct.

> The second sentence seems to contradict the first one in that it does not
> specify that the sequence of saving is important

I see no conflict here 

> (I assume that pointer_conflict exception is not thrown if we save
>  normally first and then through a pointer).

Correct

> Moreover, I don't see how the library could possibly
> achieve the "anywhere in the program" bit.

It is tricky and it does work.  I works by instantitiating a static
variable.  Static variables are constructed before main() is invoked. These
static variables register themselves in global table when constructed.  So
even though a template is used "anywhere in the program" the entry in the
global table exists before execution starts. I'm reluctant to include such
information in the manual.

> 5. Object tracking 2: It should not be possible to serialize pointers
> referencing objects of types that have track_never tracking type.

LOL - tell that to library users.  There are lots of things that users are
convinced they have to do that I don't think are a good idea.  As a library
writer I'm not in position to enforce my ideas how users should use the
library.  On this particular point I would be very suspicious about such a
usage but as practical matter I just have to include a warning and move on. 

special.html#objecttracking says:

<quote>
By definition, data types designated primitive by Implementation Level class
serialization trait are never tracked. If it is desired to track a shared
primitive object through a pointer (e.g. a long used as a reference count),
It should be wrapped in a class/struct so that it is an identifiable type.
The alternative of changing the implementation level of a long would affect
all longs serialized in the whole program - probably not what one would
intend.
</quote>

> I think serializing untracked pointers almost never makes sense. If it
> does anyway the pointed-to object can always be saved by dereferencing the
> pointer. Such an error should probably be signalled with an exception.

I don't understand this.

> 6. Object tracking 3: One should be able to activate tracking on the fly
> Rarely it makes sense to save even primitive types in tracked mode (e.g. 
> the example quoted in 6.). That's why I think setting the tracking type
> per type is not flexible enough. It should be possible to override the
> default somehow. I could imagine to save such pointers as follows:

> class T
> {
>   ...
>   int i;
>   int * pI; // always points to i
> };

> template<class Archive >
> void T::save(Archive &ar) const
> {
>     ar << track( i ); // save the int here, keep track of the pointer
>     ar << track( pI ); // only save a reference to the int
> }

> Since it is an error to save an untracked type by pointer even the second
> line needs the track( ) call.

A main function of using a trait is to avoid instantiation of code that
won't ever be used. If I understand your proposal we would have to
instantiate tracking code even if it isn't used.

But my main objection thing about this proposal is that it introduces a
runtime modality into the type traits.  This sound like it would very hard
to debug and verify.  I see lots of difficulties and very little advantage
to trying to add this.  

> 7. I think the enum tracking_type should rather be named tracking_mode as
> the _type suffix suggests something else than an enum.

I don't think the change is sufficiently compelling to justify the hassle
associated with this.

> 8. I don't understand how function instantiation as described under
> special.html#instantiation works. The description seems to indicate that
> all possible archive classes need to be included in the files of all types
> that are exported. Is that true?

True.  All archives that might be used have to be included.  This is an
artifact of using templates rather than virtual functions.  Templates
regenerate the code for each combination of serializable type and archive.
This results in faster code - but more of it.  There were strong objections
raised in the first review about the fact it used virtual functions rather
then templates - so it was changed to templates here.

> 9. The library registers all kinds of stuff with static instances. This
> precludes its use outside main().

Hmmm - that would be news to me.

Robert Ramey