[boost] [serialization] default-constructors (was Re[serialization] problem deserializing vectors)

From: Samuel Krempp (krempp_at_[hidden])
Date: 2003-10-01 08:14:14

le Wednesday 01 October 2003 11:47, ghost_at_[hidden] écrivit :

>> private: // serialization support
>>     friend class boost::serialization::access;
>>     // accesor to grant privliges to stl serialization only
>>     friend class boost::serialization::stl::access;

> One objection I have to this idea is that it decouples serialization
> library comonent but add some dependency between serialization and user
> classes. How do I know if I should add
> 
>     friend class boost::serialization::stl::access;
> 
> to a class. Naturally, I have to if I plan the serialize vectors of the
> class. It's possible to add this to every class, but then it's just extra
> typing. If I don't add it by default, then I'll have to add it the first
> time I'm going to serialize a vector of class. So the system becames
> unstable: some C++ module suddenly decides to serialize a vector of my
> class, and I have to change declarations in header.

I think this way too. Once an object is serializable, a container of those
objects should be serializable too, without any modification.
 
> I don't know how to best address the concerns you express in other
> posting, I'll try to think about it and reply. But I'll be busy till the
> end of this week, so expect some delay.

If I got it right, Robert is reluctant to have deserialization require
default-constructability, even private, since it is different things.

Obviously, for a user to make her class serializable by adding a simple
serialize member function, the serialization lib must be able to construct
an object, only to call this function on. (I'll call that a pre-object, for
clarity)
Even if default-constructing an object of this class makes no sense,
constructing a pre-object is probably possible (and even a no-op, since the
deserialization should do everything).
Banning the ability to construct a pre-object just so to avoid defining a
misleading default-constructor is a pity, as it imples defining less
concise out-of-class de-serialization functions.

I think the problem is just to dissociate this constructor from a plain
default constructor.
Making this a private default constructor is a first step, but does not
satisfy everybody as it does not make it clear what this constructor is
intended for.

What about using a constructor with a specific signature, eg :

class Deserialization {};
class Toto {
[snip]

template<class Archiver>
void serialize(Archiver & ar, int v);

private :
// constructs a pre-object for deserialization to work with.
// maybe does nothing, maybe sets data specifically :
Toto(Deserialization const&); 
  
};

I think it does provide the 'pre-object' constructor needed for
deserialization without ambiguity.
but it might not be worth requiring every serializable class to define a
specific constructor, if it is default-constructible in the first place.

Is it possible (even if only on the most modern compilers with SFINAE) to
test for the existence of this pre-object constructor, and then either use
it or resort to a plain default constructor in the deserialization code ?
If so, I think this is a neat way to let deserialization work on a
pre-object without any risk to confuse this class ability with
default-constructability.

-- 
Samuel