Re: [boost] ptr_container: ptr_map_adapter interface

From: Thorsten Ottosen (tottosen_at_[hidden])
Date: 2006-01-03 20:23:52

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

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

No, I'm saying that you should make you class hiararchy noncopyable by
default because it doesn't make sense to copy such types. I believe 
Steven Dewhurst has an item on that in his "Common Knowledge" book.

Your argumentation is weird...in the same manner I could prove your
cow pointer (or any smart pointer) is worse because it allows slicing:

cow_ptr<T> p1, p2;
...
*p1 = *p2;

!!!

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

So would I. But in reality that is impossible. Compilers wanr about 
different things and sometimes about really silly things. We have to 
live with that. ADL warnigns was one of the first I turned off on vc7.

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

The slicing is done by you...not inside container code!

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

The problem is that the STL is designed for types with value-semantics. 
The OOP domain is entirely different.

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

Well, I'm referring both to Herb Sutters book (where COW is not an 
optimization in multithreaded code) and the fact that high end
STL implementations have gone away from COW. In particular, I know
std::string in Metrowerks has abandonened it.

Anyway, I don't mind reading a nice article about pro's and cons.

-Thorsten