From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-04-29 19:11:11
"Beman Dawes" <bdawes_at_[hidden]> wrote in message
>If anyone who was present has additions or corrections, please let me know
(Beman, I cc'd you to this message.)
>* 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.<
In light of my other post entitled "Traits-based design and ODR", I now
believe that's not the best idea, and that post makes a suggestion that I
believe is quite viable.
>* 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.<
The above-mentioned suggestion solves this problem.
>* 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.<
The above-mentioned suggestion solves this problem, too.
>* 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.<
Are they referring to memory overhead due to compilers that don't perform
EBO correctly, or memory overhead that cannot be avoided while staying
within the Standard?
>* 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.<
I don't understand the usability advantage, and I'm not yet 100% convinced
of the other advantages. If you could detail a bit when you get a chance, I
would be grateful.
>* 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.)<
Wrong bet on my part it seems :o).
>* 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
I understand. For me, the argument came from the real world. I remember to
this day the bug we had in a COM transaction server. The wizard generated
wrong source code that used sp->Release() instead of sp.Release(). The code
would sometimes crash on exit. Tons of code reviews did not make a
difference. In the end, someone discovered the problem in some bug document.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk