[boost] Re: Seriialzation library draft # 18 uploaded to filessection

From: David Abrahams (dave_at_[hidden])
Date: 2004-04-12 13:12:24

Joaquín Mª López Muñoz <joaquin_at_[hidden]> writes:

> Robert Ramey ha escrito:
>
>> Joaquin Munoz wrote:
>>
>> > I think I detected a minor bug in collections_load_imp.hpp.
>> > The operator() code for archive_input_seq reads:
>>
>> > inline void operator()(Archive &ar, Container &s)
>> > {
>> >     typedef BOOST_DEDUCED_TYPENAME Container::value_type type;
>> >     stack_allocate<type> t;
>> >     load_construct_data(ar, t.address(), 0U);
>> >     ar >> make_nvp("item", t.reference());
>> >     s.push_back(t.reference());
>> >     t.address()->~type(); // undo load_construct_data above
>> > }
>>
>> > This is AFAICS not exception-safe: if say s.push_back()
>> > throws, the dtor for the stack-allocated variable t won't
>> > be called. The same problem in similar code snippets
>> > through this file. Apologies if my perception is wrong.
>>
>> Hmmm - An interesting point I never considered.  Push_back from the standard
>> library has a strong guarantee so the problem should boil down to one of the
>> constructors (copy or inplace) throwing.
>
> push_back() can also throw from the allocator if it runs out of memory,
> so you really need some proper clenaup regardless of the guarantees
> made by copying ops. Dave's suggestion of using RAII is probably the
> most elegant way to deal with the situation: in my experience, however,
> this sort of scope guards perform worse than a try{}catch(...){}. 

On a high-quality table-based EH implementation, that's often true.
That said, there are other reasons to use RAII as I pointed out.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com