Re: [boost] ptr_container: ptr_map_adapter interface
"Thorsten Ottosen" <tottosen@dezide.com> wrote in message news:<dpdofv$434$1@sea.gmane.org>...
axter wrote:
"Thorsten Ottosen" <tottosen@dezide.com> wrote in message news:<dpbv9p$k15$1@sea.gmane.org>...
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.
axter wrote:
"Thorsten Ottosen" <tottosen@dezide.com> wrote in message news:<dpdofv$434$1@sea.gmane.org>...
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
participants (9)
-
axter -
Thorsten Ottosen