Re: [boost] [shared_ptr] Why operator< uses internal_less?

Subject: Re: [boost] [shared_ptr] Why operator< uses internal_less?
From: Emil Dotchevski (emil_at_[hidden])
Date: 2008-10-10 14:48:47

On 10/9/08, joaquin_at_[hidden] <joaquin_at_[hidden]> wrote:
> emil_at_[hidden] escribió:
> > On 10/9/08, Peter Dimov <pdimov_at_[hidden]> 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
> 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