Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk