[shared_ptr] Why operator< uses internal_less?
I see that operator== and operator!= are implemented comparing the pointer inside the shared_ptr's using get(), but operator< uses _internal_less, that does a different thing. I thought that operator< would also be implemented using get(), so please, can you share the rationale behind the need for _internal_less? TIA
dariomt@gmail.com wrote:
I see that operator== and operator!= are implemented comparing the pointer inside the shared_ptr's using get(), but operator< uses _internal_less, that does a different thing.
I thought that operator< would also be implemented using get(), so please, can you share the rationale behind the need for _internal_less?
get() returns px (the raw pointer), _internal_less compares pn (the shared_count). This is peculiar, since it means that alias pointers to different subobjects would compare non-equal, but sort equivalent. I'd like to know the rationale of this, too. Sebastian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 09 October 2008 11:32 am, Sebastian Redl wrote:
dariomt@gmail.com wrote:
I see that operator== and operator!= are implemented comparing the pointer inside the shared_ptr's using get(), but operator< uses _internal_less, that does a different thing.
I thought that operator< would also be implemented using get(), so please, can you share the rationale behind the need for _internal_less?
get() returns px (the raw pointer), _internal_less compares pn (the shared_count).
This is peculiar, since it means that alias pointers to different subobjects would compare non-equal, but sort equivalent. I'd like to know the rationale of this, too.
There is a rationale in n1590. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI7ig05vihyNWuA4URAnEWAJ9e9flIoOH1blxeeYJxMD2DlaC3VQCeJjM6 AGjr+bUlqqbhvV8lLAbSn1k= =9C0j -----END PGP SIGNATURE-----
Frank Mori Hess:
On Thursday 09 October 2008 11:32 am, Sebastian Redl wrote:
dariomt@gmail.com wrote:
I see that operator== and operator!= are implemented comparing the pointer inside the shared_ptr's using get(), but operator< uses _internal_less, that does a different thing.
I thought that operator< would also be implemented using get(), so please, can you share the rationale behind the need for _internal_less?
get() returns px (the raw pointer), _internal_less compares pn (the shared_count).
This is peculiar, since it means that alias pointers to different subobjects would compare non-equal, but sort equivalent. I'd like to know the rationale of this, too.
There is a rationale in n1590.
Which is 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.
On 10/9/08, Peter Dimov <pdimov@pdimov.com> wrote:
Frank Mori Hess:
On Thursday 09 October 2008 11:32 am, Sebastian Redl wrote:
dariomt@gmail.com wrote:
I see that operator== and operator!= are implemented comparing the pointer inside the shared_ptr's using get(), but operator< uses _internal_less, that does a different thing.
I thought that operator< would also be implemented using get(), so please, can you share the rationale behind the need for _internal_less?
get() returns px (the raw pointer), _internal_less compares pn (the shared_count).
This is peculiar, since it means that alias pointers to different subobjects would compare non-equal, but sort equivalent. I'd like to know the rationale of this, too. 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. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
emil@revergestudios.com escribió:
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 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. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
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
participants (7)
-
dariomt＠gmail.com -
Emil Dotchevski -
emil＠revergestudios.com
-
Frank Mori Hess -
joaquin＠tid.es -
Peter Dimov -
Sebastian Redl