Re: [boost] [serialization] rvalues and const-correctness?

Subject: Re: [boost] [serialization] rvalues and const-correctness?
From: Robert Ramey (ramey_at_[hidden])
Date: 2008-11-09 18:28:12

David Abrahams wrote:
>> I suppose I could also wrap the return type in a "wrapper type":
>>
>>  template <class T>
>>  struct wrap_rvalue
>>  {
>>      wrap_rvalue(T const& x) : x(x) {}
>>      T x;
>>  };
>>
>>  template <class T>
>>  wrap_rvalue<T> rval(T const& x) { return wrap_rvalue<T>(x); }
>>
>>  namespace boost { namespace serialization {
>>    template <class T>
>>    struct is_wrapper<wrap_rvalue<T> > : mpl::true_ {};
>>  }}
>>
>>  ar << rval( f() );

That seems a worthy idea to me.  The net effect would be
to turn off tracking for this particular object.  So, I would I would
like to see this have a more widely understood name like
dont_track(..) and added to the "case studies" section of the
documentation. I think that the idea of temporarily turning
off tracking (or other serialization traits) would have a usage
beyond rvalues.

>>> If that isn't convenient, and one had nothing else to do, he could
>>> explore the implications of implementing your proposed
>>> specialization so that it traps at compile time if the object might
>>> be tracked.  This would mean that something like int f() would work
>>> while something
>>> like my_object f() would likely trap unless my_object was
>>> specifically marked as no_tracking.  Thinking about this just a
>>> tiny bit makes
>>> this seem attractive to me.  Of course that doesn't mean much
>>> until one sets out to actually do it.
>>
>> That's actually pretty easy to do;

LOL - well for you maybe.

Note one thing.  Its not so much the code change, its all the other stuff
that this generates:

a) code change =>

b) documentation change/ehancement.  This takes some effort to explain
why serialzation is trapped or not trapped as a "side effect" of
setting the tracking attribute.

c) user support - Even if one takes the requisite effort
to explain it, one will have to continually re-explain it as users
have what they consider surprising behavior

c) new tests - not a huge deal but still a minor pain - UNLESS
something doesn't work with this or that obscure compiler.

I'll consider it in more detail when I have the time.

Robert Ramey

P.S. I quick peek at the code below make me think that the line
(serialization::tracking_level<T>::value == track_never),
might better be replaced with:
(serialization::tracking_level<T>::value <= track_never),
RR
>>
>>
>
>
>
>> Index: interface_oarchive.hpp
>> ===================================================================
>> --- interface_oarchive.hpp (revision 3212)
>> +++ interface_oarchive.hpp (working copy)
>> @@ -28,6 +28,7 @@
>> class shared_ptr;
>> namespace serialization {
>>     class extended_type_info;
>> +    template <class T> struct tracking_level;
>> } // namespace serialization
>> namespace archive {
>> namespace detail {
>> @@ -64,6 +65,14 @@
>>         this->This()->save_override(t, 0);
>>         return * this->This();
>>     }
>> +
>> +    template<class T>
>> +    typename enable_if_c<
>> +        (serialization::tracking_level<T>::value == track_never),
>> Archive & +    >::type operator<<(T const& t){
>> +        this->This()->save_override(t, 0);
>> +        return * this->This();
>> +    }
>>
>>     // the & operator
>>     template<class T>
>>
>
>
>
>>
>>
>> --
>> Dave Abrahams
>> BoostPro Computing
>> http://www.boostpro.com
>>
>
>
>
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost