Re: [boost] Re[serialization] problem deserializing vectors

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-09-30 09:44:46

Robert Ramey wrote:
> Vladimir Prus wrote:
> >Will I get any error if I serialize this 'const' member?
>
> I believe you will when you try to load it. The library code doesn't
> specifically address the const-ness of members.  Hence,  I
> believe that reading the value (save) will succeed while
> writeing the value (load) will fail due to the const-ness.

Ok.

>
> >> a) the serializations included with the library presume
> >> the existence of a default constructor.
> >
> >That's fine with me. But, why don't allow default ctor to be private?
> >All the machinery needed to access that ctor is already there.
> >
> >The example you give directly uses non-default ctor. I agree this might be
> >necessary in some cases, but in my case, it would be much simpler if I
> >declare default ctor as private and serialization lib access that ctor.
>
> Note that it is only requried to specify a default constructor if
> a non-default one has been specified.  So in most cases the
> issue won't even arise.

Uhm... most my classes have some constructor, and in a lot of cases it's 
non-default one. So this is more like a rule, than an exception.

> Suppose we tweak things to permit access to your default
> private constructor.  In order for the program to link, V() wil
> have to be defined.  If so what should m_i be initialized with?
> Certainly, it shouldn't be left uninitialized.  

It m_i is 'const' then yes. But in all other cases, it *can* be left 
uninitialized, just because only serialization lib can call default 
constructor.

> Maybe some
> default value should be provided.  But then, we should use
>
> V(int i = 0) rather than V(int i)
>
> and we dont' need a default private constructor and the program
> compiles.

But if you add "= 0" you're making this ctor into public default ctor. What if 
there's no sensible default initialization? Let me look at the real example 
that I have

   class Variable_declaration {
    public:
        Variable_declaration(const std::string& name, 
                             const std::string& section,
                             const std::string& storage_type,
                             bool shared,
                             Whale::NonterminalType* type,
                             Whale::NonterminalInitializer* initializer,
                             std::map<std::string, long long>& constants);

Yep, I can add default values to all parameters, but that default values would 
not be sensible, and in fact the ctor will likely crash. Still, I'd like to 
serialize vectors of this type.

> My real point is that the rules for default constructor are
> forcing us to think about what we're doing.  If we step
> back a bit and consider what we're doing, The "problem"
> will often go away. I think this is one case where C++
> is saving us from ourselves.
>
> class V {
> public:
>     V(int i = 0) : m_i(i) {}

As I've said, you've just made default ctor. If serialization lib can access 
private default ctor, then I can create it and not bother about semantic, 
since serialization lib will properly initialize everything. If serialization 
lib cannot access private default ctor, then I have to make it public, which
opens a possibility for misuse by clients.

- Volodya