[boost] Re: [serialization] load_construct proposal

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-13 13:58:16

Robert Ramey <ramey_at_[hidden]> writes:

> David Abrahams wrote:
>
>>> template<class Archive ar, class T>
>>> void load(Archive & ar,  T * &t,  unsigned int file_version)
>>> {
>>>     t = NULL; 
>>>     try{  
>>>        t = new T();
>>>        ar >> *t;
>>>     }
>>>     catch(...){
>>>         delete t;
>
>>If you were to do it this way, you should do "t = NULL" here instead,
>>but...
>
> won't this leak memory if ar >> *t throws an exception?

How?  There's a delete statement right above.

I meant "do t=NULL here insteaad of upon entering the function"
because it's a waste of cycles unless an exception is thrown.

>>>         throw;
>>>     }
>>> }
>>
>
>>using a T*& out parameter makes no sense whatever to me, and
>>just seems to complicate matters, though of course I might have missed
>>something important... ohh, are you using it for overload resolution
>>so that users can provide an overload?  
>
>>Using the same T* for both >purposes like that prevents functional programming
>
> would you like to expand upon that?

In functional programming, all data is immutable.  It tends to be much
clearer to write in that style when possible:

   T* const p = foo(whatever);

than

   T* p;

   ...

   foo(whatever, p);

>>I would prefer, e.g.:
>
>>template<class T, class Archive ar> // but see below
>>T* load(Archive & ar,  unsigned int file_version)
>>{
>>    std::auto_ptr<T> t(new T());
>>    ar >> *t;
>>    return t.release();
>>}
>
> hmm ..  would you buy:
>
> template<class Archive ar, class T> // but see below
> load(Archive & ar,  T * & t, unsigned int file_version)
> {
>    t = NULL;
>     std::auto_ptr<T> ta(new T());
>     ar >> *ta;
>     t = ta.release;
>  }

I'd rather not pay for that one.

>>// Detection for operator new and operator delete
> [snip]
>
> wow - that' s mouthful - it will take a while for me to digest that.

Peter's derivation technique is simpler and better.  It flitted across
my brain but I didn't capture it.

>>> So, in light of the above, I'm not convinced that any change would
>>> be beneficial.
>
>>That may still be true, though I'm not sure.  It seems like the
>>ability to override inplace construction is important for
>>deserializing arrays.
>
> array objects are never created by the serialization system.
>
> The default array handling
>
> ar >> array
>
> resolves to
>
> for each item in array
> 	ar >> item

Which means the array elements have to be constructed somehow before
deserialization.

> There may be cases where this default handling is inapplicable.  In
> such cases the above default de-serialization of such an array will
> have to be overridden with something presumably more elaborate.

OK.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com