[boost] Re: [serialization] load_construct proposal

From: Robert Ramey (ramey_at_[hidden])
Date: 2003-10-12 23:51:04

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?

>>         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?

>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;
 }

>// Detection for operator new and operator delete
[snip]

wow - that' s mouthful - it will take a while for me to digest that.

>> 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

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.

Robert Ramey