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