Re: [boost] ptr_container: ptr_map_adapter interface

From: axter (boost_at_[hidden])
Date: 2006-01-03 19:50:02

"Thorsten Ottosen" <tottosen_at_[hidden]> wrote in message
news:<dpdofv$434$1_at_[hidden]>...
> 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.

So are you saying, that in order to safely use ptr_map, the class hierarchy
needs to be noncopyable by default? If so, I would see that as a
justification for favoring the use of the cow_ptr smart pointers over using
ptr_map, since the cow_ptr does not have such a restriction for it's safe
usage.

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

I agree that the VC7.1 warnings are BS.  However, I think most developers
would prefer to use code that doesn't require turning of any warnings.

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

For me it implies safety, and in the test I performed these containers do
not work safely, because they crash or perform unexpected behavior like
object splicing. It takes a lot of work to get containers right, and it just
not practical to expect one programmer to be able to put together a set of
containers that are going to safely emulate (or closely emulate) all the
main STL containers, and be able to work properly in all the main stream
compilers. (VC++6.0, 7.0, 7.1, 8.x, GNU 3.x, 4.0, Borland 5.x, Intel,
Comeau, etc..).

IMHO, it's far easier and safer to develop a safe smart pointer that can be
used with the existing safe, reliable, and well tested STL containers.

It's also easier for a user to learn how to use a container of smart
pointers who's container interface matches that which they're already
familiar with.

> >>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 try not to deal with reputations, and deal with facts.  I rather take a
more scientific approach, which involves testing and measuring. You can not
measure reputation.