Boost logo

Boost :

From: Thorsten Ottosen (tottosen_at_[hidden])
Date: 2006-01-02 14:35:16

axter wrote:
> "Slawomir Lisznianski" <public_at_[hidden]> wrote in message
> news:<donook$li2$1_at_[hidden]>...
>>I've been using ptr_map lately and have a few questions regarding its
>>Below is a signature of `insert' function as declared in
>>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:
> 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


> 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


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


Boost list run by bdawes at, gregod at, cpdaniel at, john at