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;
>>> t = new T();
>>> ar >> *t;
>>> delete t;
>>If you were to do it this way, you should do "t = NULL" here instead,
> 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.
>>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);
>>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
> 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
> 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
> 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.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk