[boost] Re: Curaçao: reaction to smart pointer proposal

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-04-29 19:11:11

"Beman Dawes" <bdawes_at_[hidden]> wrote in message
news:4.3.2.7.2.20020428143101.00b6ef60_at_mailhost.esva.net...
>If anyone who was present has additions or corrections, please let me know
offline.<

(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
question.<

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.

Andrei