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