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(...){}. Your mileage may vary. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo