[smart_ptr][thread][test] breaking change on shared_ptr operator bool.
Hi, https://svn.boost.org/trac/boost/changeset/81780 " Use explicit operator bool when available; ..." introduces a breaking change on shared_ptr in Boost.Thread and Boost.Test at least. I would preferred if this breaking change was announced and why not added conditionally so that the user could move smoothly to the new semantic. Anyway, I wanted to make this evident so that the Boost maintainer using this facility fixes their code as soon as possible. Best, Vicente
Le 08/12/12 12:11, Vicente J. Botet Escriba a écrit :
Hi,
https://svn.boost.org/trac/boost/changeset/81780 " Use explicit operator bool when available; ..." introduces a breaking change on shared_ptr in Boost.Thread and Boost.Test at least. I would preferred if this breaking change was announced and why not added conditionally so that the user could move smoothly to the new semantic.
Anyway, I wanted to make this evident so that the Boost maintainer using this facility fixes their code as soon as possible.
Thread: Committed revision 81788. Test: Committed revision 81791. Vicente
On Sat, Dec 8, 2012 at 12:44 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Le 08/12/12 12:11, Vicente J. Botet Escriba a écrit :
Hi,
https://svn.boost.org/trac/boost/changeset/81780 " Use explicit operator bool when available; ..." introduces a breaking change on shared_ptr in Boost.Thread and Boost.Test at least. I would preferred if this breaking change was announced and why not added conditionally so that the user could move smoothly to the new semantic.
Anyway, I wanted to make this evident so that the Boost maintainer using this facility fixes their code as soon as possible.
What's the rationale for this breaking change? Isn't compatibility with previous Boost releases more important? -- Olaf
On Mon, Dec 10, 2012 at 7:13 PM, Olaf van der Spek <ml@vdspek.org> wrote:
On Sat, Dec 8, 2012 at 12:44 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Le 08/12/12 12:11, Vicente J. Botet Escriba a écrit :
Hi,
https://svn.boost.org/trac/boost/changeset/81780 " Use explicit operator bool when available; ..." introduces a breaking change on shared_ptr in Boost.Thread and Boost.Test at least. I would preferred if this breaking change was announced and why not added conditionally so that the user could move smoothly to the new semantic.
Anyway, I wanted to make this evident so that the Boost maintainer using this facility fixes their code as soon as possible.
What's the rationale for this breaking change? Isn't compatibility with previous Boost releases more important?
I'd consider implicit conversion to bool more a bug than a feature. Just my 5 cents.
On Mon, Dec 10, 2012 at 4:17 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
What's the rationale for this breaking change? Isn't compatibility with previous Boost releases more important?
I'd consider implicit conversion to bool more a bug than a feature. Just my 5 cents.
Thanks for the cents, but I don't. So what's your point? -- Olaf
On Mon, Dec 10, 2012 at 7:22 PM, Olaf van der Spek <ml@vdspek.org> wrote:
On Mon, Dec 10, 2012 at 4:17 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
What's the rationale for this breaking change? Isn't compatibility with previous Boost releases more important?
I'd consider implicit conversion to bool more a bug than a feature. Just my 5 cents.
Thanks for the cents, but I don't. So what's your point?
My point is that the code that relies on this behaviour is better be fixed anyway and the change helps detecting such code. Peter has already pointed out that standard pointers also behave that way, so in the end the change improves portability.
On Mon, Dec 10, 2012 at 4:27 PM, Peter Dimov <lists@pdimov.com> wrote:
Olaf van der Spek wrote:
What's the rationale for this breaking change?
Compatibility with C++11?
The 'old' boost::shared_ptr seemed to work fine on C++11.
Isn't compatibility with previous Boost releases more important?
Is it?
I think it is. -- Olaf
Olaf van der Spek wrote:
On Mon, Dec 10, 2012 at 4:27 PM, Peter Dimov <lists@pdimov.com> wrote:
Olaf van der Spek wrote:
What's the rationale for this breaking change?
Compatibility with C++11?
The 'old' boost::shared_ptr seemed to work fine on C++11.
Sure. It seems that you're being deliberately obtuse for rhetorical reasons, but all right. In C++11, the idiomatic way to make a class convertible to bool is via an explicit operator bool. The language has been specifically changed to support this use case. The standard library has been changed to use this idiom for each of its convertible to bool types, including std::shared_ptr. For better or worse, this will be how convertible to bool C++11 types will behave.
On Mon, Dec 10, 2012 at 5:23 PM, Peter Dimov <lists@pdimov.com> wrote:
Olaf van der Spek wrote:
On Mon, Dec 10, 2012 at 4:27 PM, Peter Dimov <lists@pdimov.com> wrote:
Olaf van der Spek wrote:
What's the rationale for this breaking change?
Compatibility with C++11?
The 'old' boost::shared_ptr seemed to work fine on C++11.
Sure. It seems that you're being deliberately obtuse for rhetorical reasons, but all right.
In C++11, the idiomatic way to make a class convertible to bool is via an explicit operator bool. The language has been specifically changed to support this use case. The standard library has been changed to use this idiom for each of its convertible to bool types, including std::shared_ptr. For better or worse, this will be how convertible to bool C++11 types will behave.
I know. And boost::shared_ptr behaving the same as std::shared_ptr is nice, I'm just wondering whether that's more important than maintaining compatibility with older Boost releases. What real problem with keeping the old behavor have? BTW, I'm really just wondering. -- Olaf
Olaf van der Spek-3 wrote
On Mon, Dec 10, 2012 at 5:23 PM, Peter Dimov <
lists@
> wrote:
Olaf van der Spek wrote:
On Mon, Dec 10, 2012 at 4:27 PM, Peter Dimov <
lists@
> wrote:
Olaf van der Spek wrote:
What's the rationale for this breaking change?
Compatibility with C++11?
The 'old' boost::shared_ptr seemed to work fine on C++11.
Sure. It seems that you're being deliberately obtuse for rhetorical reasons, but all right.
In C++11, the idiomatic way to make a class convertible to bool is via an explicit operator bool. The language has been specifically changed to support this use case. The standard library has been changed to use this idiom for each of its convertible to bool types, including std::shared_ptr. For better or worse, this will be how convertible to bool C++11 types will behave.
I know. And boost::shared_ptr behaving the same as std::shared_ptr is nice, I'm just wondering whether that's more important than maintaining compatibility with older Boost releases. What real problem with keeping the old behavor have?
Imagine you need to use boost::shared_ptr in a part of your application and std::shared_ptr in another part. It would be surprising if the behavior for the same operation is not the same, isn't it? I think Boost libraries implementing c++11 libraries should be as close as possible as the standard. This doesn't mean that the author can not make some deviations. Respect to compatibility, it is always better to have a deprecation period, but the required change in this case is so minor that documenting the break and how to take care of it should be enough. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/smart-ptr-thread-test-breaking-change-on-... Sent from the Boost - Dev mailing list archive at Nabble.com.
Vicente J. Botet Escriba wrote:
Hi,
https://svn.boost.org/trac/boost/changeset/81780 " Use explicit operator bool when available; ..." introduces a breaking change on shared_ptr in Boost.Thread and Boost.Test at least.
What code does it break?
Le 08/12/12 15:20, Peter Dimov a écrit :
Vicente J. Botet Escriba wrote:
Hi,
https://svn.boost.org/trac/boost/changeset/81780 " Use explicit operator bool when available; ..." introduces a breaking change on shared_ptr in Boost.Thread and Boost.Test at least.
What code does it break? Code like
bool thread::joinable() const BOOST_NOEXCEPT { return get_thread_info(); // COMPILE ERROR } which I have replaced by bool thread::joinable() const BOOST_NOEXCEPT { return get_thread_info()!=0; } Is there a better way? Best, Vicente
Vicente J. Botet Escriba wrote:
Le 08/12/12 15:20, Peter Dimov a écrit :
Vicente J. Botet Escriba wrote:
Hi,
https://svn.boost.org/trac/boost/changeset/81780 " Use explicit operator bool when available; ..." introduces a breaking change on shared_ptr in Boost.Thread and Boost.Test at least.
What code does it break?
Code like
bool thread::joinable() const BOOST_NOEXCEPT { return get_thread_info(); // COMPILE ERROR }
Yes, this is a bit unfortunate side effect of the language specification of "explicit operator bool". It does not get invoked in return statements such as the one above, and it does not get invoked when calling a function that takes a bool. The second case makes sense pragmatically, but the first doesn't. Still, the principle behind the specification is that an explicit operator bool is only invoked when a language construct such as if, while, or operator! needs a bool, and the above case is not one of those situations. Since all of the standard library in C++11, including std::shared_ptr, has been specified to use explicit operator bool, and since the committee did not display any enthusiasm for changing this status quo in some way so that the code above could continue to work, I think that we better get used to it. :-)
which I have replaced by
bool thread::joinable() const BOOST_NOEXCEPT { return get_thread_info()!=0; }
Is there a better way?
I think that this way is fine.
On 12/9/2012 8:11 AM, Peter Dimov wrote:
Vicente J. Botet Escriba wrote:
Le 08/12/12 15:20, Peter Dimov a écrit :
Vicente J. Botet Escriba wrote:
Hi,
https://svn.boost.org/trac/boost/changeset/81780 " Use explicit >> operator bool when available; ..." introduces a breaking change on >> shared_ptr in Boost.Thread and Boost.Test at least.
What code does it break?
Code like
bool thread::joinable() const BOOST_NOEXCEPT { return get_thread_info(); // COMPILE ERROR }
Yes, this is a bit unfortunate side effect of the language specification of "explicit operator bool". It does not get invoked in return statements such as the one above, and it does not get invoked when calling a function that takes a bool. The second case makes sense pragmatically, but the first doesn't. Still, the principle behind the specification is that an explicit operator bool is only invoked when a language construct such as if, while, or operator! needs a bool, and the above case is not one of those situations.
Since all of the standard library in C++11, including std::shared_ptr, has been specified to use explicit operator bool, and since the committee did not display any enthusiasm for changing this status quo in some way so that the code above could continue to work, I think that we better get used to it. :-)
which I have replaced by
bool thread::joinable() const BOOST_NOEXCEPT { return get_thread_info()!=0; }
Is there a better way?
I think that this way is fine.
FWIW I use: bool thread::joinable() const BOOST_NOEXCEPT { return !!get_thread_info(); } Jeff
On 10/12/2012 15.05, Jeff Flinn wrote:
On 12/9/2012 8:11 AM, Peter Dimov wrote:
Vicente J. Botet Escriba wrote:
Le 08/12/12 15:20, Peter Dimov a écrit :
Vicente J. Botet Escriba wrote:
Hi,
https://svn.boost.org/trac/boost/changeset/81780 " Use explicit >> operator bool when available; ..." introduces a breaking change on >> shared_ptr in Boost.Thread and Boost.Test at least.
What code does it break?
Code like
bool thread::joinable() const BOOST_NOEXCEPT { return get_thread_info(); // COMPILE ERROR }
Yes, this is a bit unfortunate side effect of the language specification of "explicit operator bool". It does not get invoked in return statements such as the one above, and it does not get invoked when calling a function that takes a bool. The second case makes sense pragmatically, but the first doesn't. Still, the principle behind the specification is that an explicit operator bool is only invoked when a language construct such as if, while, or operator! needs a bool, and the above case is not one of those situations.
Since all of the standard library in C++11, including std::shared_ptr, has been specified to use explicit operator bool, and since the committee did not display any enthusiasm for changing this status quo in some way so that the code above could continue to work, I think that we better get used to it. :-)
which I have replaced by
bool thread::joinable() const BOOST_NOEXCEPT { return get_thread_info()!=0; }
Is there a better way?
I think that this way is fine.
FWIW I use:
bool thread::joinable() const BOOST_NOEXCEPT { return !!get_thread_info(); }
That's horrible. Regards Gaetano Mendola
On 12/12/2012 00.45, Olaf van der Spek wrote:
On Wed, Dec 12, 2012 at 12:40 AM, Gaetano Mendola <mendola@gmail.com> wrote:
That's horrible.
What's wrong with it? Can't we have somewhat more constructive posts. This isn't Twitter... ;) It's quite a simple idiom to get a bool from an expression.
You don't need to get a bool from an expression there, you need to return true if the thread is joinable so a return get_thread_info() != 0; will do the job. Also about compatibility, changing the operator bool in a library available for 11 years will break a lot of code out there, if you really plan to remove it for whatever reason leave it in place for a few version, issuing warning at compile time (at least only people treating warnings as errors will be affected). Regards Gaetano Mendola
On 12/12/2012 2:46 AM, Gaetano Mendola wrote:
On 12/12/2012 00.45, Olaf van der Spek wrote:
On Wed, Dec 12, 2012 at 12:40 AM, Gaetano Mendola <mendola@gmail.com> wrote:
That's horrible.
What's wrong with it? Can't we have somewhat more constructive posts. This isn't Twitter... ;) It's quite a simple idiom to get a bool from an expression.
You don't need to get a bool from an expression there, you need to return true if the thread is joinable so a
return get_thread_info() != 0;
will do the job.
So does: return !!get_thread_info(); Jeff
On 12/12/2012 14.21, Jeff Flinn wrote:
On 12/12/2012 2:46 AM, Gaetano Mendola wrote:
On 12/12/2012 00.45, Olaf van der Spek wrote:
On Wed, Dec 12, 2012 at 12:40 AM, Gaetano Mendola <mendola@gmail.com> wrote:
That's horrible.
What's wrong with it? Can't we have somewhat more constructive posts. This isn't Twitter... ;) It's quite a simple idiom to get a bool from an expression.
You don't need to get a bool from an expression there, you need to return true if the thread is joinable so a
return get_thread_info() != 0;
will do the job.
So does:
return !!get_thread_info();
You really like it, don't you? Do whatever you wish but in my opinion write a !!get_thread_info(); over a more clear get_thread_info() != 0; means to immolate simplicity over the altar of the cleverness. Regards Gaetano Mendola -- http://cpp-today.blogspot.it/
participants (7)
-
Andrey Semashev -
Gaetano Mendola -
Jeff Flinn -
Olaf van der Spek -
Peter Dimov -
Vicente Botet -
Vicente J. Botet Escriba