"bwood" <brass@mailvault.com> wrote in message news:<20060103232237.47DB9B64A52@gateway.mailvault.com>...
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
Thorsten Ottosen wrote: perform the
boost pointer containers.
I would. COW doesn't have a good reputation.
I agree with Thorsten and will be interested in the results of the tests. I think the ptr_containers need more work, but I don't think they should be replaced because something might be better. If an alternative proves to be better and is adopted by people, the ptr_containers will not be used and will be a footnote in history. In the meantime I think the competition between approaches is interesting.
Brian www.webEbenezer.net
I don't think the pointer containers should be removed from the boost library. (At least not the vector, list, and deque). I don't think that using cow_ptr or copy_ptr will be a completely win-win situation. I predict that the boost pointer containers will do better at memory management, although I have not yet developed a good test for this. Also, I do like the interface ptr_vector has via it's iterators, in that you don't have to dereference the iterator in order to access the pointee. I think the cow_ptr should be used as the default method for creating containers of pointers, and that the current boost pointer containers should be used when memory management is the more important factor for a particular requirement. I'm not sure about the ptr_set and ptr_map classes, because I haven't seen any example code usage that would have it work with an abstract type. From my test so far, it seems that they're interface is too different from their STL counter parts, and the logic does not seem to be consistent with the other pointer containers, nor with each other. Hopefully, someone here can provide me with some working example code.