"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > "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?
See right below: :o) > > 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 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 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. > 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. 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? This might be a good precedent though. > > 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, 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). > > 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. Hurray! Thanks. Indeed it feels so very good to hear that from a member of the committee. 'Coz the discussion on shared_ptr at http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1397.html does look to me like... when there's no anchor, what to do? Sail! :o)) Andrei _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
