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:
> > >
> > > At the last meeting, the committee accepted Herve Broenimann's proposal
> > >
> > >
> > > to change std::shared_ptr's operator< to compare get(). I don't
> > > 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
> 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.
Reverge Studios, Inc.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk