BOOST_NOEXCEPT macro?
Should we add a BOOST_NO_NOEXCEPT config macro, and then provide a header with something like: #ifdef BOOST_NO_NOEXCEPT # define BOOST_NOEXCEPT throw() #else # define BOOST_NOEXCEPT noexcept #endif --Beman
Should we add a BOOST_NO_NOEXCEPT config macro, and then provide a header with something like:
#ifdef BOOST_NO_NOEXCEPT # define BOOST_NOEXCEPT throw() #else # define BOOST_NOEXCEPT noexcept #endif
I assume this is a new C++0x feature? I haven't come across this one before! If so then yes, by all means add this, and the above logic to boost/config/suffix.hpp. John.
On Thu, Feb 17, 2011 at 8:12 AM, John Maddock <boost.regex@virgin.net> wrote:
Should we add a BOOST_NO_NOEXCEPT config macro, and then provide a header with something like:
#ifdef BOOST_NO_NOEXCEPT # define BOOST_NOEXCEPT throw() #else # define BOOST_NOEXCEPT noexcept #endif
Actually, we need two macros. While the about may still be useful, the most common use is going to be: #ifdef BOOST_NO_NOEXCEPT # define BOOST_NOEXCEPT #else # define BOOST_NOEXCEPT noexcept #endif See lots of examples in the current working paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3225.pdf
I assume this is a new C++0x feature? I haven't come across this one before!
Yep. From Doug Gregor. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3051.html Be careful. I think there has been some churn since Doug's original paper.
If so then yes, by all means add this, and the above logic to boost/config/suffix.hpp.
Let me come back with a firmer proposal. --Beman
I believe it's not that simple. As I remember, throw() means the same thing as nothrow only in MSVC. For example, under GCC you'll have to use __attribute__((nothrow)). Correct me if I'm wrong. -- Best regards, Alexander Fokin, http://elric.ru.
On Thu, Feb 17, 2011 at 11:36 AM, Alexander Fokin <apfokin@gmail.com> wrote:
I believe it's not that simple.
As I remember, throw() means the same thing as nothrow only in MSVC. For example, under GCC you'll have to use __attribute__((nothrow)).
Correct me if I'm wrong.
You're right. In general, throw() has runtime semantics and can produce runtime overhead in the form of increased executable size and occasionally reduced speed. noexcept has only compile-time semantics. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 17 February 2011 11:45, Dave Abrahams <dave@boostpro.com> wrote:
On Thu, Feb 17, 2011 at 11:36 AM, Alexander Fokin <apfokin@gmail.com> wrote:
I believe it's not that simple.
As I remember, throw() means the same thing as nothrow only in MSVC. For example, under GCC you'll have to use __attribute__((nothrow)).
Correct me if I'm wrong.
You're right. In general, throw() has runtime semantics and can produce runtime overhead in the form of increased executable size and occasionally reduced speed. noexcept has only compile-time semantics.
noexcept has runtime semantics as well, doesn't it? If you are in a function declared noexcept(true) and an exception tries to escape, std::terminate is called. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
Nevin Liber wrote:
On 17 February 2011 11:45, Dave Abrahams <dave@boostpro.com> wrote:
On Thu, Feb 17, 2011 at 11:36 AM, Alexander Fokin <apfokin@gmail.com> wrote:
As I remember, throw() means the same thing as nothrow only in MSVC. For example, under GCC you'll have to use __attribute__((nothrow)).
You're right. In general, throw() has runtime semantics and can produce runtime overhead in the form of increased executable size and occasionally reduced speed. noexcept has only compile-time semantics.
noexcept has runtime semantics as well, doesn't it? If you are in a function declared noexcept(true) and an exception tries to escape, std::terminate is called.
I think they were referring to "noexcept" specifically (and thus to noexcept(false)). _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Thu, Feb 17, 2011 at 2:55 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
On 17 February 2011 11:45, Dave Abrahams <dave@boostpro.com> wrote:
On Thu, Feb 17, 2011 at 11:36 AM, Alexander Fokin <apfokin@gmail.com> wrote:
I believe it's not that simple.
As I remember, throw() means the same thing as nothrow only in MSVC. For example, under GCC you'll have to use __attribute__((nothrow)).
Correct me if I'm wrong.
You're right. In general, throw() has runtime semantics and can produce runtime overhead in the form of increased executable size and occasionally reduced speed. noexcept has only compile-time semantics.
noexcept has runtime semantics as well, doesn't it? If you are in a function declared noexcept(true) and an exception tries to escape, std::terminate is called.
Grrr! Right, I forgot they added that behavior against my advice. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Thu, Feb 17, 2011 at 12:51 PM, Dave Abrahams <dave@boostpro.com> wrote:
On Thu, Feb 17, 2011 at 2:55 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
On 17 February 2011 11:45, Dave Abrahams <dave@boostpro.com> wrote:
On Thu, Feb 17, 2011 at 11:36 AM, Alexander Fokin <apfokin@gmail.com> wrote:
I believe it's not that simple.
As I remember, throw() means the same thing as nothrow only in MSVC. For example, under GCC you'll have to use __attribute__((nothrow)).
Correct me if I'm wrong.
You're right. In general, throw() has runtime semantics and can produce runtime overhead in the form of increased executable size and occasionally reduced speed. noexcept has only compile-time semantics.
noexcept has runtime semantics as well, doesn't it? If you are in a function declared noexcept(true) and an exception tries to escape, std::terminate is called.
Grrr! Right, I forgot they added that behavior against my advice.
Do I understand correctly that they replaced the lame throw() standard behavior, to call unexpected() if an exception attempts to propagate out of the function, with calling std::terminate() instead? Am I missing something, isn't this equally lame? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Thu, Feb 17, 2011 at 7:02 PM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
On Thu, Feb 17, 2011 at 12:51 PM, Dave Abrahams <dave@boostpro.com> wrote:
On Thu, Feb 17, 2011 at 2:55 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
On 17 February 2011 11:45, Dave Abrahams <dave@boostpro.com> wrote:
On Thu, Feb 17, 2011 at 11:36 AM, Alexander Fokin <apfokin@gmail.com> wrote:
I believe it's not that simple.
As I remember, throw() means the same thing as nothrow only in MSVC. For example, under GCC you'll have to use __attribute__((nothrow)).
Correct me if I'm wrong.
You're right. In general, throw() has runtime semantics and can produce runtime overhead in the form of increased executable size and occasionally reduced speed. noexcept has only compile-time semantics.
noexcept has runtime semantics as well, doesn't it? If you are in a function declared noexcept(true) and an exception tries to escape, std::terminate is called.
Grrr! Right, I forgot they added that behavior against my advice.
Do I understand correctly that they replaced the lame throw() standard behavior, to call unexpected() if an exception attempts to propagate out of the function, with calling std::terminate() instead? Am I missing something, isn't this equally lame?
Don't get me started :-( -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (7)
-
Alexander Fokin -
Beman Dawes -
Dave Abrahams -
Emil Dotchevski -
John Maddock -
Nevin Liber -
Stewart, Robert