Re: [boost] ptr_container: ptr_map_adapter interface

From: Thorsten Ottosen (tottosen_at_[hidden])
Date: 2006-01-03 06:51:25

axter wrote:
> 
> "Thorsten Ottosen" <tottosen_at_[hidden]> wrote in message
> news:<dpbv9p$k15$1_at_[hidden]>...
> 
>>axter wrote:

>>>>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?
> 
> 
> One of the reasons to use pointers, is so that you don't have object
> slicing.  ptr_map is a container of pointers, but you still get object
> slicing.  IMHO, that inconsistent at best, and unreliable at worse.

>>>4.  When assigning value via operator[] from one container to 
>>>another, you get object splicing for derived types
>>
>>So?
> 
> See above comment:

This is your own fault....you should make your class hierarchy 
noncopyable by default.

If you really want to assign the pointers, then use replace().

> 
>>>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?
> 
> 
> Reliable in that you get expected interface when compiling.
> Reliable in that you get expected behavior at runtime.

I think you would use the term "familiar" here. Reliability for me 
implies safety or performance guarantees.

> 
>>Switching to a deep-copying smart pointer can have significant
>>performance implications, particularly (but not only) with compilers 
>>without RTO, like vc6.
>>
> 
> 
> VC6 doesn't even compile using the boost::ptr_map or boost::ptr_set?.....

well, it's basically an ancient compiler and I don't have the resources
to port to it anymore.

> You can eliminate performance implications by using a deep-copying smart
> pointer like the cow_ptr, which I previously posted.
> Moreover, I wouldn't be surprise if the cow_ptr was able to out perform the
> boost pointer containers.

I would. COW doesn't have a good reputation.

> I'm currently working on making a comparison between the boost pointer
> containers and copy_ptr/cow_ptr.
> I also plan to do performance test, so that the comparison will be more
> complete.

Ok, for what its worth, I'm looking forward to reading it. You might 
consider a test comparing the binary size too.

> Below I list some of the issues found using the boost pointer containers.
> Some of the issues are by design, and some are not.  Whether it's by design
> or not, I still consider the issues relevant in a comparison.
> The test was performed using boost_1_33_0 and VC++ 7.1, 6.0, and GNU 3.x.
> You can download the test code via following link:
> http://code.axter.com/BoostPtrContainerTestCode.zip
> The current test code is a little hard to read, but once I'm completely done
> with all the test, I will clean it up.
> 
> Please feel free to correct me on any of the items listed below.  Most of
> the items listed below, you'll find relevant comments in the above test
> code.

I will comment on these later tonight.

-Thorsten