"Andrei Alexandrescu" <[EMAIL PROTECTED]> writes: > There's also a contradiction in there. The document nicely continues "One of > the reasons shared_ptr has been so successful is that in the great majority > of cases it supplies all the features that users need." However, only two > paragraphs below, in response to committee's "Proliferation of Standard > Library smart pointers is a serious concern", we read the following: > "scoped_ptr, scoped_array, and shared_array have been removed from the > proposal." > > Am I the only one who sees the fly in the ointment?
Maybe. What is the fly in this case? > If shared_ptr is the factotum, how come there are some other pointers in > boost that needed to be removed from the proposal? Why was their > functionality deemed necessary? 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 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. That, at least, is my impression of why the other 3 smart pointer types were removed from the proposal. > Also, what's the deal with weak_ptr? It's not really a pointer at all, though for a while we thought it was (http://lists.boost.org/MailArchives/boost/msg34530.php). In the end it is still the best name anyone could come up with. > 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? > The committee also mentions that "LWG members are very concerned > that "you don't have to pay for what you don't use." I was one of those. > To this, the answer is "Issues related to weak_ptr are a side issue > that can be resolved after the basic proposal is accepted. Also, be > aware that different implementation techniques are possible, and > they may make various speed vs space tradeoffs. These choices are > not mandated by the proposal." I didn't find that part very satisfying, either. > I think much more detail is fair at this point. Why resolve an issue > after the proposal is accepted? What implementation techniques are > possible, and what tradeoffs do they make? IMHO, the interface > proposed (notably the custom deleter) does mandate quite some. I agree with that. The wording you cite sure seems like it's sweeping aside valid concerns without truly addressing them. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
