I've been suggested to forward here a post (that I initially made to the
boost list) initiating a discussion on the shared_ptr proposal, here it is
(a little abridged :o)):

"Beman Dawes" <bdawes@acm.org> wrote in message
news:4.3.2.7.2.20030125135225.0226db40@mailhost.esva.net...
> At 04:25 PM 1/24/2003, Jeffrey Yasskin wrote:
>
>  >Just out of curiosity, which boost libraries are likely to be proposed
to
>  >the committee?
>
> See http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1397.html

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.

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

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?"

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?

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?


Andrei


---
[ 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                       ]

andrewalex@hotmail.com ("Andrei Alexandrescu") wrote in message news:<b14l2h$v1o3a$1@ID-14036.news.dfncis.de>...
> I've been suggested to forward here a post (that I initially made to the
> boost list) initiating a discussion on the shared_ptr proposal, here it is
> (a little abridged :o)):
>
> "Beman Dawes" <bdawes@acm.org> wrote in message
> news:4.3.2.7.2.20030125135225.0226db40@mailhost.esva.net...
> > At 04:25 PM 1/24/2003, Jeffrey Yasskin wrote:
> >
> >  >Just out of curiosity, which boost libraries are likely to be proposed
>  to
> >  >the committee?
> >
> > See http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1397.html
>
> The smart pointer proposal is unconvincing to me.

There hasn't been any formal proposal yet. Please don't confuse items
on the committee's Library TR issues list with formal proposals. The
issues list entries just serve as status indications and placeholders
for the actual proposals. The comments in issues lists are just that -
comments to help refresh people's memories. They are totally
unofficial and shouldn't be confused with actual committee positions.

The deadline for Library TR proposals is this April, so presumably the
actual proposal will be available once the pre- or post-meeting
mailings are posted.

HTH,

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