Re: [boost] [ptr_map] Boost pointer containers, where is the working map type?

From: Thorsten Ottosen (tottosen_at_[hidden])
Date: 2006-01-02 15:06:40

axter wrote:

 > "Slawomir Lisznianski" <public_at_[hidden]> wrote in message
 > news:<donook$li2$1_at_[hidden]>...
 >
 >> Hello,
 >>
 >> I've been using ptr_map lately and have a few questions regarding its
 >> interface.
 >>
 >> Below is a signature of `insert' function as declared in 
ptr_map_adapter:
 >>
 >> std::pair<iterator,bool>  insert( key_type& k, value_type x );
 >>
 >> Why is `k' a non-const reference?

it's a matter about exception-safety.

see the FAQ.

 >> To imply ownership transfer, couldn't `x' be of
 >> `std::auto_ptr<value_type>' type instead?

right. the next release will have overloads taking auto_ptr<T> as well 
as T*.

 >> What happend to std::pair as an argument of insert? Was symmetry with
 >> std::map dropped for a reason here?
 >>

yes, exception-safety.

 >> From my test, it doesn't seem as though ptr_map has consistent and 
reliable
 >
 > implementation.

Do you care to explain in detail what that means?

 > I recommend that boost replace the pointer containers with the following
 > smart pointers:
 > http://code.axter.com/copy_ptr.h
 > http://code.axter.com/cow_ptr.h
 >
 > Example usage:
 > std::map<int, cow_ptr<foo> > MyPtrMap;
 >
 > The above type gives you more functionality then the boost::ptr_map type,
 > and of course, it's interface matches the std::map interface.
 > Where as the boost::ptr_map type has the following problems:
 > 1.  Doesn't allow you to use an abstract pointer

Really?

 > 2.  Requires a non-constant argument for the insert function

Right, to give exception-safety.

 > 3.  Requires value semantics for the operator[] function

?

 > 4.  When assigning value via operator[] from one container to 
another, you
 > get object splicing for derived types

So?

 > 5.  It doesn't seem to compile on VC++ 6.0, and when it compiles on 
VC++ 7.1
 > you get compiler warnings

Yes, vc7.1 warns about a lot of things, particular ADL. Turn it off.

 > If you use cow_ptr instead, you don't have the above problems.
 >
 > There are similar problems in the boost::ptr_set class, which also can be
 > replaced with cow_ptr or copy_ptr
 > std::set<cow_ptr<foo> > MyPtrSet;
 >
 > IMHO, the entire boost pointer container set of classes can be 
replace with
 > either cow_ptr and/or copy_ptr, and the result would be a more reliable,

reliable in what way?

Switching to a deep-copying smart pointer can have significant 
performance implications, particularly (but not only) with compilers 
without RTO, like vc6.

-Thorsten