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

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-01-27 18:43:19

"Andrei Alexandrescu" <andrewalex_at_[hidden]> wrote in message
news:b14cq2$2km$1_at_main.gmane.org...
> "Beman Dawes" <bdawes_at_[hidden]> wrote in message
> news:4.3.2.7.2.20030125135225.0226db40_at_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
>
> This is yet another bad PR move, but then I thought, if voicing an opinion
> around here constitutes a problem, then the problem is not mine. So here
> goes.

PR stands for public relations AFAIK. Why is it a PR move ? If you think it
is a bad PR move, why is it "another bad PR move", ie. what was the previous
bad PR move ?

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

I agree with you here. I think that one should theoretically be able to
release a shared_ptr if there are no other copies of it around. However
could you explain further the situation(s) in which this is likely to occur
?

I understand COM but normally one uses a smart pointer with COM that is tied
into the referencing counting mechanism of the COM interface to which the
pointer is referring. Without getting too deeply into a discussion of COM, I
would be reticent to use a general smart pointer mechanism with it but would
use one designed specifically to work with COM interfaces such as those
provided by Microsoft and Borland with their C++ offerings. I don't doubt
that a generalized smart pointer that worked correctly with COM might be
useful, but then should we consider CORBA and any other generalized
object-oriented technologies in the mix. Where does one stop ?

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

Perhaps this has already been done, or perhaps you mean others to look at
your own Loki smart pointer to understand what you think is missing from
Boost shared_ptr, but I think you need to either specify what you believe
are the specific weaknesses of the Boost shared_ptr class, present your own
smart pointer to Boost as a better alternative within the Boost library, or
present your own smart pointer to the C++ committee as a better or
additional alternative to the Boost shared_ptr. Your last paragraph is not
an argument for anything because one can not guess what "tons others" means.