Hi all,

"A proposal to add general purpose smart pointers to the library"
http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1450.html
explicitly allows a reference-linked implementation (III.A.4). Why?
According to Andrei Alexandrescu (Modern C++ Design 7.5) the only
advantage of that is that no extra object (reference counter) has to
be allocated. I have not been able to think of or find any other
advantage. But what to do with the deleter then, whose type is not in
the shared_ptr template parameter list? There must be something I'm
missing, or otherwise a linked list implementation of shared_ptr is
forced to allocate at least some free store for the deleter (or a
vtable) -- rendering the advantage void.

Regards,
Rogier

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

R.C.van.Dalen@umail.leidenuniv.nl (Rogier van Dalen) wrote in message news:<670c04cd.0401030138.4be9496d@posting.google.com>...
> Hi all,
>
> "A proposal to add general purpose smart pointers to the library"
> http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1450.html
> explicitly allows a reference-linked implementation (III.A.4). Why?
> According to Andrei Alexandrescu (Modern C++ Design 7.5) the only
> advantage of that is that no extra object (reference counter) has to
> be allocated. I have not been able to think of or find any other
> advantage. But what to do with the deleter then, whose type is not in
> the shared_ptr template parameter list? There must be something I'm
> missing, or otherwise a linked list implementation of shared_ptr is
> forced to allocate at least some free store for the deleter (or a
> vtable) -- rendering the advantage void.

The standard tries to avoid dictating particular implementation
techniques. Implementors are in a better position to judge what will
meet their user's implementation needs than standards writers. As long
as the behavior specified by the standard is achieved, any
implementation technique is fair game.

A linked list implementation of shared_ptr might choose to optimize
the common case of no deleter being present. A single bit is
sufficient for that. Some architechures have extra bits available in
pointers for that sort of use. Who knows what other optimizations
implementators may think of for a particular platform?

--Beman Dawes

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Rogier van Dalen" <R.C.van.Dalen@umail.leidenuniv.nl> wrote:
<snip>
> "A proposal to add general purpose smart pointers to the library"
> http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1450.html
> explicitly allows a reference-linked implementation (III.A.4). Why?
> According to Andrei Alexandrescu (Modern C++ Design 7.5) the only
> advantage of that is that no extra object (reference counter) has to
> be allocated. I have not been able to think of or find any other
> advantage. But what to do with the deleter then, whose type is not in
> the shared_ptr template parameter list? There must be something I'm
> missing, or otherwise a linked list implementation of shared_ptr is
> forced to allocate at least some free store for the deleter (or a
> vtable) -- rendering the advantage void.

No expert has replied, so I'll offer my opinion. :)

The standard should put as few constraints on implementations as possible.
Implementers can be expected to experiment with various implemenation
strategies, and pick the one which is best overall according to the criteria
appropriate for thier platform. It may turn out that the linked-list
implementation never offers any significant advantages, for the reason you
mention; in this case, you will not see many implementations adopt this
approach. But why prevent them from trying?

The only advantage I can think of which prohibiting linked implementations
would offer is that use_count could be guaranteed to be reasonably
efficient. However, the lack of this guarantee has not detracted from the
usefulness of boost::shared_ptr, as far as I know.

I would be interested to know if there any widely used shared_ptr-like
templates which are implemented as lists and also offer custom deleters (the
linked_ptr which is part of the boost documentation doesn't).

Jonathan


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message:
>
> I would be interested to know if there any widely used shared_ptr-like
> templates which are implemented as lists and also offer custom deleters
(the
> linked_ptr which is part of the boost documentation doesn't).
>

Here I'm talking about custom deleters which are not specified as template
parameters.

Jonathan


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> The standard tries to avoid dictating particular implementation
> techniques. Implementors are in a better position to judge what will
> meet their user's implementation needs than standards writers. As long
> as the behavior specified by the standard is achieved, any
> implementation technique is fair game.

That's true of course. As Jonathan Turkanis pointed out, the only advantage
of not allowing reference linked implementations would be use_count()'s
efficiency - which is, indeed, not good enough a reason to bar such an
implementation.

> A linked list implementation of shared_ptr might choose to optimize
> the common case of no deleter being present. [...]

I don't think that is allowed, is it? The last shared_ptr may be shared_ptr
<void> which would not have a clue about the correct deleter.

> Who knows what other optimizations
> implementators may think of for a particular platform?

That's true enough though; thanks for your replies.

Regards,
Rogier




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]