Re: [boost] Re: Deadline for the Standard Library Technical Report

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-01-28 09:00:16

From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>

[...]

> The smart pointer proposal is unconvincing to me. This, of course, comes
at
> no surprise. There's some conjecture in the reference document at
> http://www.boost.org/libs/smart_ptr/shared_ptr.htm such as "The support
for
> custom deallocators does not impose significant overhead" or "My opinion
is
> that the added functionality is worth the cost" etc. Not what one would
> like to hear about a one-size-fits-most standard library implementation.

There is no formal proposal yet. The sentences you quoted are "design
notes". :-)

You can read "The support for custom deallocators does not impose
significant overhead" as "In this implementation, the support for custom
deallocators does not impose significant overhead", if you like.

In the real proposal, "My opinion is that the added functionality is worth
the cost" will be... expressed differently, and we'll try to include enough
motivating examples to justify it.

You might want to also take a look at

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/s
mart_ptr/sp_techniques.html

(disclaimer: work in progress.)

> On to the FAQ. (I will skip over the first three Q&A with which I totally
> disagree.)

I am interested in your disagreement with the first Q&A.

> Q.Why doesn't shared_ptr provide a release() function?
> A.shared_ptr cannot give away ownership unless it's unique() because the
> other copy will still destroy the object.
>
> The answer doesn't answer the question. The next natural question is, "ok,
> but if the pointer is unique(), can I benefit of a release() function that
> returns a bool telling me whether the release worked or not?"

Or "can I benefit from a release() that only works if unique() and throws an
exception otherwise?"

You are right, the answer is not convincing. A better answer would be: "if
you had release(), what would you do with the returned pointer?"

It is possible to get around that, of course. One possibility would be to
drop half of the features, to make "delete release();" safe. Another would
be for release() to return a std::pair< T*, boost::function<void ()> >.

> It turns out that in COM the need of relinquishing ownership back to the
> system (or another entity) is a common case. Has anyone used shared_ptr
> with COM extensively?

I already answered this question:

http://lists.boost.org/MailArchives/boost/msg23319.php

(20 Jan 2002).

You must have missed that.

> Q. Why doesn't shared_ptr provide (your pet feature here)?
> A. Because (your pet feature here) would mandate a reference counted
> implementation or a linked list implementation, or some other specific
> implementation. This is not the intent.
>
> This is a presupposition. Someone wants to mandate lazy
> initialization/specific dereference testing/specific initialization
> testing/tons others. Would any of these require a refcounted/reflinked
> implementation?

No, of course not. This Q&A has been written in response to my (old) request
that shared_ptr should provide an id() that allows people to group pointers
into equivalence classes based on ownership. This is useful if you have a
set of shared_ptr's and you need to process every object once, for example,
during serialization to disk.

The current implementation allows a shared_ptr<void> or weak_ptr<void> to be
used as an identifier, i.e. the user can maintain a std::map<weak_ptr<void>,
int> to attach an int to ownership groups.

The Q&A is a "catch all", it was never the intent to apply it to all
proposed features. Perhaps we should just remove it, as its relevance has
been lost as the design evolved.

Thank you for taking the time to review shared_ptr, and for your comments.