On 10/9/08, joaquin@tid.es <joaquin@tid.es> wrote:
On 10/9/08, Peter Dimov <pdimov@pdimov.com> wrote: http://open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1590.html
At the last meeting, the committee accepted Herve Broenimann's proposal
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2637.pdf
to change std::shared_ptr's operator< to compare get(). I don't
emil@revergestudios.com escribió: particularly
like the specifics of that paper, but we'll probably need to change boost::shared_ptr (and weak_ptr) to match.
I don't see a reason to make this change in Boost. It is impossible to predict how many bugs it will introduce in user code, although it could -- perhaps too late -- highlight problems unforeseen by N2637. IMHO, the committee is crazy for making this kind of untested semantic changes in shared_ptr this late in the game.
Well, the committee is polishing the designing of the *future* std::shared_ptr, so they are not concerned about backwards compatibility issues. Another question is whether boost::shared_ptr should follow suit.
When I said issues I didn't necessarily mean backwards-compatibility issues. The reality is that the current semantics of boost::shared_ptr have been tested for many years in large scale C++ projects on all platforms on earth, and the "new" semantics have not. Given this track record, and if it was up to me, I would be asking for solid evidence that such a change is required: - specific use cases that are enabled by the new semantics, - specific problems caused by the current semantics. If it ain't broken, don't fix it, IMO. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode