Boost logo

Boost :

From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2006-12-19 16:49:27


Daniel Wallin wrote:
> Thorsten Ottosen wrote:
>>The first argument needs to be a reference:
>>
>>int key = 1;
>>my_map.insert( key, new int(22) );
>>
>>1.34 adds the followinf overload:
>>
>> template< class U >
>> std::pair<iterator,bool>
>> insert( const key_type& key, std::auto_ptr<U> x )
>>
>>which does allow the key to be an rvalue (just don't create the auto_ptr
>>in the function call).
>
>
> Thorsten, I've suggested this before:
>
> http://article.gmane.org/gmane.comp.lib.boost.devel/132706/match=re+ptr+container+boost+map
>
> but I'll try again.

Thanks. I have no recollection about the first time you suggested it. I
must have missed that. Sorry.

> Taking the key by reference guarantees nothing
> except confused users.

Well, it why does it not protect against leaking the object?

> A more sane way to solve this would be to delay
> possible implicit conversions until after the pointer has been protected:
>
> template <class K, class U>
> std::pair<iterator, bool> insert(K const& k, U* p)
> {
> std::auto_ptr<U> owned(p);
> this->insert(implicit_cast<key_type const&>(k), owned);
> }

It seems like a good idea, but I think it will not give the same protection:

   std::string foo();
   boost::ptr_map<std::string,T> m;
   m.insert( foo(), new T );

merely copying the return value of foo() could throw IFAICT.

I see that Dave A. reponded with:

>Could you please explain what you're saying? On the surface, that
>sounds like a flawed rationale on many levels. The arguments to a
>function can be evaluated in any order -- they can even be
>interleaved. Taking a parameter by non-const reference does nothing
>to prevent the corresponding expression from throwing.

really? Binding to a non-const refence rarely throws, although changing
foo to

   std::string& foo();

it could throw before returning.

> Is this
> another example of false user protection?

Perhaps. Let's discuss it.

-Thorsten


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk