Re: [Boost-users] [1.33][ptr_container] bug in erase() in associativecontainers?

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-08-23 16:22:40

"Malte Clasen" <news_at_[hidden]> wrote in message
news:deg2p6$ce0$1_at_sea.gmane.org...
> Hi,
>
> the erase() method (defined in associative_ptr_container.hpp, line 104)
> seems a bit strange:
>
>          size_type erase( const key_type& x ) // nothrow
>          {
>              BOOST_ASSERT( !this->empty() );
>              iterator i = find( x );                     // nothrow
>              if( i == this->end() )                      // nothrow
>                  return 0;                               // nothrow
>              this->remove( i );                          // nothrow
>              return this->c_private().erase( i.base() ); // nothrow
>          }
>
>
http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/ptr_container/detail/associative_ptr_container.hpp?rev=1.4&view=markup
>
> My compiler (vc++7.1) complained about the unknown find() when I called
> erase() on ptr_map. "find" is not declared neither in this class nor in
> its base class. The closest valid call I could think of would be
>
> this->c_private().find( x )

hm...maybe I overlooked something...I will look at that later.

> . But there seems to be a nicer solution:
>
>          size_type erase( const key_type& x ) // nothrow
>          {
>              BOOST_ASSERT( !this->empty() );
>              return this->c_private().erase( x ); // nothrow
>          }
>
> This compiles fine and does just what I want it to do, even nothrow is
> guaranteed (I checked the vc++ reference for std::map). Now I wonder why
> erase() is implemented differently in Boost 1.33. Is there anything I
> overlooked?

deleting the object itself...not just the pointer.

> Btw, is there a rationale for the declaration of insert()?
>
> std::pair<iterator,bool> insert( key_type& k, value_type x );
>
>
http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/ptr_container/ptr_map_adapter.hpp?rev=1.12&view=auto
>
> Passing key_type by non-const reference caused some unaesthetic
> constructs in my code because return values (temporaries) cannot be used
> directly.

indeed. but this is the only way to gain exception-safety.

-Thorsten