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

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-28 14:16:51

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

> "David Abrahams" <dave_at_[hidden]> wrote in message
> I don't know about others, but when I read that three other pointers have
> been removed from the proposal to make it palatable and that there's word
> about a fourth, I start to doubt that shared_ptr is "so successful" and that
> "in the great majority of cases it supplies all the features that users
> need".

I guess it depends on whether you consider the lack of a feature (like
copyability) to be a feature.  Remember that the standard makes no
prohibition on extensions that allow nonstandard constructs to
compile, so in the context of a standard specification, scoped_ptr
doesn't really add anything to shared_ptr.  You could make a similar
argument about the *_array jobbies.

>> I think you fail to appreciate that the standards committee is
>> ultimately a somewhat different audience from the boost user
>> community.  The committee seems to be very much more conservative in
>> what it is willing to accept and consider.  A proposal for the
>> standard must be written with even greater rigor than Boost
>> documentation should be, and that can increase its length and
>> complexity.
>
> I'm very very happy to hear that, because the smart_ptr discussion
> at http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1397.html
> looks to me, at least in comparison to all other discussions on the
> same page, more like a agile plea based on subjective opinion that
> glosses over certain details, rather than a technical, objective
> discussion.

If you think so, maybe you should be bringing that up on the LWG
reflector or comp.std.c++?

>> I think there's a fear that a proposal containing 4 smart pointer
>> types (like one containing 5 template parameters <wink>) might be
>> hard enough for the committee to swallow that nothing at all would
>> be accepted.
>
> My impression, on the contrary, was that the committee was much more
> willing to look into a policy-based approach than into an inherently
> limited and suboptimal design.

As an observer on the scene, that didn't appear to me to be the case.
Maybe the document doesn't characterize the mood well.  In any case,
the committee is inherently more-willing to consider designs for which
it has proposals than those for which it does not.  I don't think I
need to remind you that there has been no proposal submitted for a
PBSP.  Also, once again, I think you'd get a much better sense of the
actual mood at present if you brought this up on the LWG reflector.

> Ah, one thing. Binary compatibility and EXE/DLL issues are mentioned
> with shared_ptr. For what I know, this is the very first component
> in the Standard ever addresses this particular issue. Why not vector
> or string?  

I'm certainly not the one to answer that question, since those
components predate my participation.  Once again, maybe a different
forum would yield better answers?

>> > And Sherlock Holmes would also like to ask, why are there new smart
>> > pointers added to boost on a regular basis?
>>
>> Where does this question come from?  When was the last time we added a
>> new smart pointer?
>
> I don't know about adding

In that case, "when did you stop beating your wife?" <wink>

> but I press the "down" arrow only a few times and what do I see?
> Only this year, some convo about shifted_ptr and intrusive_ptr and
> cyclic_ptr. That's a mouthful already :o). If shared_ptr covers 99%
> of use(r)s, there sure is a lot of fuss over the remaining 1%
> :o).

Sure, people (especially library designers) are interested in other
smart pointer designs.  That doesn't gainsay the fact that shared_ptr
seems to work well in most cases.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution