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+cont...

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