Subject: Re: [boost] [ptr_container] Questionable strong guarantee of ptr_map::insert()
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2009-08-20 10:01:59
Kazutoshi Satoda skrev:
> Thanks for the follow ups.
> Now I noticed that the problem is not only in ptr_map::insert(). The
> same problem seems wide spread in the whole ptr_container library.
> I'll make the following 2 tickets in boost trac if nobody objects nor
> gives better suggestion.
> 1. (Type: Bugs)
> False strong guarantee in ptr_container documentation
Right, it should be replaced with the basic guarantee and a note saying
the object is deleted when an exception is thrown.
> 2. (Type: Feature Requests)
> Provide strong guaranteed overloads in ptr_container
Hm. Do you propose to break the existing interface?
> Steven Watanabe wrote:
>> David Abrahams wrote:
>>> I think the implementation of ptr_map::insert is probably as correct as
>>> can be in doing that deletion (i.e. the docs are wrong, not the
>>> implementation), but if I had written ptr_map I'd have given it an
>>> auto_ptr parameter instead.
>> There is an overload that takes an auto_ptr.
> Yes, but unfortunately, it doesn't provide strong guarantee, as same as
> the raw pointer version.
> And also, the current auto_ptr pass-by-value version can be a
> An casual user of ptr_map will likely write a code at first like this:
> map.insert(some_key(...), new value(...));
> This doesn't compile by design. Then the user will look for the docs to
> find alternative ways, find the auto_ptr version, and modify the code to
> shut off the strange compile error, like this:
> map.insert(some_key(...), std::auto_ptr<value>(new value));
> This does compile, with the risk of subtle memory leaks. But the user
> can hardly notice the problem, and would think, "Aha, I can guess, the
> use of auto_ptr is the fix for exception-safety problem which the FAQ
> mentions. The library taught me that with the error. So nice."
People need to initialize smart pointers in seperate statements.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk