RE: [boost] Re: Future of shared_ptr

From: Bjorn.Karlsson_at_[hidden]
Date: 2002-06-18 08:18:24

> From: James Curran [mailto:JamesCurran_at_[hidden]]
> Sent: den 18 juni 2002 13:04
> To: boost_at_[hidden]
> Subject: [boost] Re: Future of share_ptr
> 
> 
> RE: [boost] Future of share_ptr    What was the reaction at 
> the Curacao
> meeting?

This is an excerpt from a note posted by Beman after the meeting:

--- smart pointer proposal status ---

[Curacao: The LWG expressed serious concerns about the proposal, and about 
other smart pointer issues:

* Because user needs are so varied, Standard Library smart pointers should 
support a full feature model, including user supplied behavior. A 
policy-based design is seen as the only candidate likely to meet this 
criteria.

* Because of the need for a single smart pointer to recommend for everyday 
use, and for interoperability between third-party libraries, shared_ptr is 
seen as a likely candidate for standardization. The LWG is interested 
primarily in the interface and with interoperability, although aware that 
implementation might well be forwarded to a policy-based smart pointer.

* Standard Library smart pointers should be viewed as a whole to ensure 
consistency and interoperability; thus the idea of unrelated proposals for 
non-policy based and policy-based smart pointers meets much resistance.

* Proliferation of Standard Library smart pointers is a serious concern; if 
a policy-based smart pointer and a compatible shared_ptr were available, 
they would be preferred; scoped_ptr, scoped_array, and shared_array were 
not viewed favorably by many LWG members.

* LWG members are very concerned that "you don't have to pay for what you 
don't use." This is particularly true of memory; increased memory use due 
to multiple inheritance or to accommodate weak_ptr, for example, is viewed 
as a serious problem.

* LWG members are concerned about usability and flexibility of designs with 
multiple template policy parameters.  A single policy parameter, with 
policy composition by chained inheritance, would seem to have usability, 
flexibility, and inter-policy communication advantages.

* In a quick (no discussion of exact meaning of terms) straw poll, the vote 
was 9 1/2 yes, 0 no, to the question of whether or not a policy-based smart 
pointer should support arrays.  (The 1/2 vote was from someone undecided.)

* There was a bit of discussion and show of hands on non-member versus 
member functions.  No clear guidance resulted; the existing use of member 
functions in std::auto_ptr and the Boost smart pointers muddied the 
question.

Note that the LWG is still considers many of these concerns as subject to 
change, as proposals are refined.]

--- end ---

Bjorn