Re: [Boost-users] ptr_container: ptr_map.insert() not compiling?

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