From: Christian Thäter (chth_at_[hidden])
Date: 2001-07-12 17:30:36
> This comes up enough that I've added a FAQ entry:
> Q. Why doesn't shared_ptr use a linked list implementation?
> A. A linked list implementation does not offer enough advantages
> to offset the added cost of an extra pointer. See timings page.
> I've also added a reference to one of the other FAQ entries:
> (Those interested in policy based smart pointers should read Modern
> C++ Design by Andrei Alexandrescu.)
> If you look at the Smart Pointer Timings
> http://www.boost.org/libs/smart_ptr/smarttests.htm, the real questions
> Why haven't we added an allocator to shared_ptr?
> Why haven't we proposed an invasive_shared_ptr?
> While there are some technical issues, I'm afraid part of the answer is
> simple inertia. And of course shared_ptr as it now stands is plenty
> enough for the majority of uses.
Sure i agree that there possible more efficient implementations.
My point was not concerning the implementation. I want to focus on the
semantic and if we agree on some semantic, then think about the best
implemetation. Actually we have the simple and efficent std::auto_ptr with
it's ownership-transistion and boost::shared_ptr whith it's lossy
(on reset/assign) semantic's.
So the question is, "Is there a need for other semantics?", like:
"Shall it ensure strict resource sharing which keeps track of
reset/assign operations for all instances of a pointer?"
"Shall pointer-construction have predictable timing behaviour?"
"Shall pointer construction never throw?"
I believe that future C++ needs more high-level support with no
side-effect's in it's semantics, at least optional. Sure building smarter
things often involves higher cost, but on the advantage of easier use of
the components. So, I experimented the last days a bit with these
pointers, learned alot about the important points, now I implement the
linked_ptr and linked_array classes according to the boost/smart_ptr
interfaces for my own use, if anyone is intrested i can send/post/upload
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk