--- At Mon, 18 Dec 2006 15:04:11 -0500, Jeff F wrote:

Duane Murphy wrote:

...

I'm trying to use boost::ptr_map<> and cannot get calls insert to compile.

I'm on Mac OS X using gcc 3.3 with Xcode.

Even the most basic code fails to compile:

boost::ptr_map< in, int* > my_map;

shouldn't this be(ie: no *):

boost::ptr_map< int, int > my_map;

Sorry, copy and paste error. Yes, it should be but the error remains: error: no matching function for call to `boost::ptr_map > >::insert(int, int*&)' ptr_map_adapter.hpp:392: error: candidates are: std::pair::iterator, bool> boost::ptr_map_adapter::insert(typename boos t::ptr_container_detail::ptr_map_adapter_base::key_type&, typename boost::ptr_container_detail::ptr_map_adapter_base::value_type) [with T = int, VoidPtrMap = std::map > >, CloneAllocator = boost::heap_clone_allocator] ...Duane

--- At Tue, 19 Dec 2006 11:46:40 +0100, Thorsten Ottosen wrote:

Duane Murphy wrote:

...

I'm trying to use boost::ptr_map<> and cannot get calls insert to compile.

I'm on Mac OS X using gcc 3.3 with Xcode.

Even the most basic code fails to compile:

boost::ptr_map< in, int* > my_map; int * val = new int( 22 ); my_map.insert( 1, val );

See http://www.boost.org/libs/ptr_container/doc/ptr_map_adapter.html

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 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).

And here I was assuming it was something to do with the value... Thank you. I now recall reading something about that, but it wasn't clear to me at the time that it was talking about the key. This fixes the problem. ...Duane

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 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 std::pair insert(K const& k, U* p) { std::auto_ptr<U> owned(p); this->insert(implicit_cast(k), owned); }

It seems like a good idea, but I think it will not give the same protection: std::string foo(); boost::ptr_mapstd::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