Re: [Boost-users] [serialization] serialization of pointers to primitive types?

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-09-16 13:50:40

JOAQUIN LOPEZ MU?Z wrote:
> Hello Robert,
>
> ----- Mensaje original -----
> De: Robert Ramey <ramey_at_[hidden]>
> Fecha: Sábado, Septiembre 16, 2006 8:01 am
> Asunto: Re: [Boost-users] [serialization] serialization of pointers
> to primitive types?
>
>> Serialization of pointers to primitive data types is prohibited.
>> I'm pretty sure this is mentioned in the documentation. ( don't
>> have  the exact reference handy)
>
> I've persued the docs and in every place where this is referred
> to, the statement is that primitive types are not tracked, which
> is IMHO different than serialization of pointers to primitive
> types being forbidden. Examples:
>
> - Serializable concept:
>
>   "A type T is Serializable if and only if one of the following
>   is true:
>   * it is a primitive type.
>   [...]
>   * it is a pointer to a Serializable type.[...]"
>
> from which it can be deduced that a pointer to a primitive type
> is serializable.

Touche

> - Object tracking:
>
>   "Default tracking traits are:
>   * For primitive, track_never.[...]"
>
> At the risk of repeating myself, I understand what serializing
> a pointer to a non-tracked type involves. This is not the same
> as not being able to serialize the pointer in the first place,
> which is what happens with primitive types, to my dismay.

Correct, I lumped the two ideas - serialization and tracking together
in my brain. Clearly an error.

> Wouldn't it be an option that pointers to
> primitive types will be handled as non-tracked? What would be
> the overhead of that option? In case this is an option, please
> consider my vote for inclusion as a new feature in Boost 1.35.

OK - that would work fine - but I also believe it would trip the
infamous "const trap" so that might have to be considered.

>> The way to serialize pointer to primitives
>> (serialization_level::prmitive) is to use BOOST_STRONG_TYPEDEF to
>> define a new type and specify serialization function for it.  This
>> won't work for std::string so you'll have to make a trivial
>> derivation of std::string if you want to serialize a pointer to a
>> std::string.

> The problem with that is that it is an intrusive solution that
> complicates things when dealing with generic code. Sometimes,
> it can be just impossible to do that intrusive change or require
> the user to do it. From this restriction, for instance, we have
> that
>
>   std::set<int*>
>
> is not serializable as is. Telling the user to change her
> definition to something like
>
>   std::set<BOOST_STRONG_TYPEDEF(...)*>
>
> just for the sake of serializability could be unacceptable in
> some (many?) situations.

Note that I like the BOOST_STRONG_TYPEDEF for a number
of reasons.  Basically it attaches more information to an int at compile
time and this makes generic programming easier.  So my reaction is
if you're serializing std::set<int *> maybe your should use
BOOST_STRONG_TYPEDEF earliear to better identify one's
integer at compile time.  After all - we don't want to mix apples and 
oranges!.

So when faced with this my view would be

BOOST_STRONG_TYPEDEF(int, number_of_apples)

class X {
    number_of_apples m_apple_count;
   ...
    template ...
    serialize(...
};

Now we can say
operator==(number_of_apples &, number_of_oranges &){
    BOOST_STATIC_ASSERT(mpl::false?);
}

And when one uses std::set<number_of_apples *> we have no problems
with serialization.

I realize I digress. I realize it is not necessarily or desirable for a 
library
writer to enforce such a discipline - even if he were to agree with me
that its a good approach - which is extremely unlikely in any case.

So - although the problem never comes up for me I concede your
point.  I have erroneously confused the identity of two concepts -
serialization and tracking.  From that standpoint I'm inclined
to make the change you suggest. The only concern is that it would break
one of the user traps that inhibits certain user behavior because it will 
almost
surely lead to intractible problems.  Dealing with the trap is a pain - but 
its
much less painful than dealing with user's who have done something that
is permitted and seems natural to do end up having archives that cannot
be read or recovered.  I believe that serializing someting like std::set<int 
*>
will eventually lead to such problems eventually in most cases.

To summarize, you're correct.  But I'm concerned that just "fixing" the
code will create new set of problems.

Robert Ramey