[inspect] exceptions (FW: [Boost-users] no exceptions)
From Boost Users ML:
From: Hochhaus, Andrew I would like to use boost with BOOST_NO_EXCEPTIONS [1] and the g++ -fno-exceptions flag. However, it appears that some spots in boost library code:
a) throw exceptions with the "raw" throw keyword [instead of BOOST_THROW_EXCEPTION or boost::throw_exception] b) use try ... catch blocks without "#ifnef BOOST_NO_EXCEPTIONS" guards
Wouldn't it be a good idea to add checks for these to the inspect tool? Also, non-empty exception specifications are discouraged by Boost guidelines - should appropriate checks be added too? Best regards, Robert
On Mon, Mar 21, 2011 at 6:39 PM, Robert Kawulak <robert.kawulak@gmail.com> wrote:
From Boost Users ML:
From: Hochhaus, Andrew I would like to use boost with BOOST_NO_EXCEPTIONS [1] and the g++ -fno-exceptions flag. However, it appears that some spots in boost library code:
a) throw exceptions with the "raw" throw keyword [instead of BOOST_THROW_EXCEPTION or boost::throw_exception] b) use try ... catch blocks without "#ifnef BOOST_NO_EXCEPTIONS" guards
Wouldn't it be a good idea to add checks for these to the inspect tool? Also, non-empty exception specifications are discouraged by Boost guidelines - should appropriate checks be added too?
+1 Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Mon, Mar 21, 2011 at 6:39 PM, Robert Kawulak <robert.kawulak@gmail.com> wrote:
From Boost Users ML:
From: Hochhaus, Andrew I would like to use boost with BOOST_NO_EXCEPTIONS [1] and the g++ -fno-exceptions flag. However, it appears that some spots in boost library code:
a) throw exceptions with the "raw" throw keyword [instead of BOOST_THROW_EXCEPTION or boost::throw_exception] b) use try ... catch blocks without "#ifnef BOOST_NO_EXCEPTIONS" guards
Wouldn't it be a good idea to add checks for these to the inspect tool? Also, non-empty exception specifications are discouraged by Boost guidelines - should appropriate checks be added too?
+1
I don't think that Boost libraries are required to support non-conforming compilers or operation modes of compilers, therefore adding inspect check for a workaround for such non-comforming behaviour would be wrong, I think. - Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40
From: Vladimir Prus Emil Dotchevski wrote:
<robert.kawulak@gmail.com> wrote:
From: Hochhaus, Andrew a) throw exceptions with the "raw" throw keyword [instead of BOOST_THROW_EXCEPTION or boost::throw_exception] b) use try ... catch blocks without "#ifnef BOOST_NO_EXCEPTIONS" guards
Wouldn't it be a good idea to add checks for these to the inspect tool? Also, non-empty exception specifications are discouraged by Boost guidelines - should appropriate checks be added too?
+1
I don't think that Boost libraries are required to support non-conforming compilers or operation modes of compilers, therefore adding inspect check for a workaround for such non-comforming behaviour would be wrong, I think.
For try/catch blocks you're right. As to BOOST_THROW_EXCEPTION, it is not only about supporting non-conforming compilers. It is a customisation point for exception handling behaviour of Boost libraries just like BOOST_ASSERT is for assert, so it is important that it's used consistently in all Boost libraries to make it make sense. It also automatically adds useful exception origin information like file/line/function, which makes debugging programs using Boost faster and easier. I think using BOOST_THROW_EXCEPTION should be added to the Boost guidelines page in the first place, but Boost.Inspect should also enforce this. As to exception specifications, IIRC this has nothing to do with non-conforming compilers - it is a general C++ style guideline and Boost guidelines page also recommends it. Best regards, Robert
On Tue, Mar 22, 2011 at 1:38 AM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Emil Dotchevski wrote:
On Mon, Mar 21, 2011 at 6:39 PM, Robert Kawulak <robert.kawulak@gmail.com> wrote:
From Boost Users ML:
From: Hochhaus, Andrew I would like to use boost with BOOST_NO_EXCEPTIONS [1] and the g++ -fno-exceptions flag. However, it appears that some spots in boost library code:
a) throw exceptions with the "raw" throw keyword [instead of BOOST_THROW_EXCEPTION or boost::throw_exception] b) use try ... catch blocks without "#ifnef BOOST_NO_EXCEPTIONS" guards
Wouldn't it be a good idea to add checks for these to the inspect tool? Also, non-empty exception specifications are discouraged by Boost guidelines - should appropriate checks be added too?
+1
I don't think that Boost libraries are required to support non-conforming compilers or operation modes of compilers, therefore adding inspect check for a workaround for such non-comforming behaviour would be wrong, I think.
Why use BOOST_THROW_EXCEPTION to throw? - Typically, there is no need to do anything else to support BOOST_NO_EXCEPTIONS builds; - Enables boost::exception_ptr, so the exceptions you throw can be transported between threads; - Enables boost::error_info, so users can attach stuff to exceptions. - Enables better messages from boost::diagnostic_information. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
2011/3/22 Emil Dotchevski <emildotchevski@gmail.com>
Why use BOOST_THROW_EXCEPTION to throw?
- Typically, there is no need to do anything else to support BOOST_NO_EXCEPTIONS builds;
- Enables boost::exception_ptr, so the exceptions you throw can be transported between threads;
- Enables boost::error_info, so users can attach stuff to exceptions.
- Enables better messages from boost::diagnostic_information.
+1 What about boost/detail/no_exceptions_support.hpp? Could that file be moved to boost/exception for public use? I use it, but don't feel comfortable with it being in the detail directory. Regards, Kris
Message du 22/03/11 20:18 De : "Krzysztof Czainski" <1czajnik@gmail.com> A : boost@lists.boost.org Copie à : Objet : Re: [boost] [inspect] exceptions (FW: [Boost-users] no exceptions)
2011/3/22 Emil Dotchevski
Why use BOOST_THROW_EXCEPTION to throw?
- Typically, there is no need to do anything else to support BOOST_NO_EXCEPTIONS builds;
- Enables boost::exception_ptr, so the exceptions you throw can be transported between threads;
- Enables boost::error_info, so users can attach stuff to exceptions.
- Enables better messages from boost::diagnostic_information.
+1
What about boost/detail/no_exceptions_support.hpp? Could that file be moved to boost/exception for public use? I use it, but don't feel comfortable with it being in the detail directory.
+1 As BOOST_THROW_EXCEPTION is not enough to support BOOST_NO_EXCEPTIONS builds. These macros clearly help to achieve this goal. Best, Vicente Example of use from the file: void foo() { BOOST_TRY { ... } BOOST_CATCH(const std::bad_alloc&) { ... BOOST_RETHROW } BOOST_CATCH(const std::exception& e) { ... } BOOST_CATCH_END } With exception support enabled it will expand into: void foo() { { try { ... } catch (const std::bad_alloc&) { ... throw; } catch (const std::exception& e) { ... } } } With exception support disabled it will expand into: void foo() { { if(true) { ... } else if (false) { ... } else if (false) { ... } } }
On Tue, Mar 22, 2011 at 12:16 PM, Krzysztof Czainski <1czajnik@gmail.com> wrote:
2011/3/22 Emil Dotchevski <emildotchevski@gmail.com>
Why use BOOST_THROW_EXCEPTION to throw?
- Typically, there is no need to do anything else to support BOOST_NO_EXCEPTIONS builds;
- Enables boost::exception_ptr, so the exceptions you throw can be transported between threads;
- Enables boost::error_info, so users can attach stuff to exceptions.
- Enables better messages from boost::diagnostic_information.
+1
What about boost/detail/no_exceptions_support.hpp? Could that file be moved to boost/exception for public use? I use it, but don't feel comfortable with it being in the detail directory.
This header is news to me. :) Maybe something like this could become a documented part of Boost Exception. I don't understand why the macros defined in no_exceptions_support.hpp expand to if("") { } else if(!"") { } etc. in BOOST_NO_EXCEPTIONS builds. Expanding to if(true) { } else if(false) { } seems more appropriate to me. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Message du 22/03/11 20:30 De : "Emil Dotchevski" A : boost@lists.boost.org Copie à : Objet : Re: [boost] [inspect] exceptions (FW: [Boost-users] no exceptions)
On Tue, Mar 22, 2011 at 12:16 PM, Krzysztof Czainski <1czajnik@gmail.com> wrote:
2011/3/22 Emil Dotchevski
Why use BOOST_THROW_EXCEPTION to throw?
- Typically, there is no need to do anything else to support BOOST_NO_EXCEPTIONS builds;
- Enables boost::exception_ptr, so the exceptions you throw can be transported between threads;
- Enables boost::error_info, so users can attach stuff to exceptions.
- Enables better messages from boost::diagnostic_information.
+1
What about boost/detail/no_exceptions_support.hpp? Could that file be moved to boost/exception for public use? I use it, but don't feel comfortable with it being in the detail directory.
This header is news to me. :) Maybe something like this could become a documented part of Boost Exception.
I don't understand why the macros defined in no_exceptions_support.hpp expand to if("") { } else if(!"") { } etc. in BOOST_NO_EXCEPTIONS builds. Expanding to if(true) { } else if(false) { } seems more appropriate to me.
It seems that there were some issues with Borland # if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564)) # define BOOST_TRY { if ("") # define BOOST_CATCH(x) else if (!"") # else # define BOOST_TRY { if (true) # define BOOST_CATCH(x) else if (false) # endif Best, Vicente
Message du 22/03/11 20:30 De : "Emil Dotchevski" A : boost@lists.boost.org Copie à : Objet : Re: [boost] [inspect] exceptions (FW: [Boost-users] no exceptions)
On Tue, Mar 22, 2011 at 12:16 PM, Krzysztof Czainski <1czajnik@gmail.com> wrote:
What about boost/detail/no_exceptions_support.hpp? Could that file be moved to boost/exception for public use? I use it, but don't feel comfortable with it being in the detail directory.
This header is news to me. :) Maybe something like this could become a documented part of Boost Exception.
I'm wonderyn if the following wouldn't be more natural void foo() { BOOST_TRY { ... } BOOST_CATCH(const std::bad_alloc&) { ... BOOST_RETHROW } BOOST_CATCH(const std::exception& e) { ... } BOOST_CATCH_ALL { ... } } See the attached file. Best, Vicente
Vicente BOTET <vicente.botet <at> wanadoo.fr> writes:
On Tue, Mar 22, 2011 at 12:16 PM, Krzysztof Czainski <1czajnik <at> gmail.com> wrote:
What about boost/detail/no_exceptions_support.hpp? [...]
I'm wonderyn if the following wouldn't be more natural
void foo() { BOOST_TRY { ... } BOOST_CATCH(const std::bad_alloc&) { ... BOOST_RETHROW } BOOST_CATCH(const std::exception& e) { ... } BOOST_CATCH_ALL { ... } }
If you refer to why BOOST_CATCH_END is needed in the original formulation, consider the following: if(so) BOOST_TRY{ foo(); } BOOST_CATCH(const std::exception& e){ bar(); BOOST_RETHROW } else baz(); This, using your variation, expands to if(so) if (true){ foo(); } else if (false){ bar(); } else baz(); which is equivalent to (note the braces) if(so){ if (true){ foo(); } else if (false){ bar(); } else{ baz(); } } which is clearly not the intention. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Message du 23/03/11 22:13 De : "Joaquin M Lopez Munoz" A : boost@lists.boost.org Copie à : Objet : Re: [boost] [inspect] exceptions (FW: [Boost-users] no exceptions)
Vicente BOTET wanadoo.fr> writes:
On Tue, Mar 22, 2011 at 12:16 PM, Krzysztof Czainski <1czajnik gmail.com> wrote:
What about boost/detail/no_exceptions_support.hpp? [...]
I'm wonderyn if the following wouldn't be more natural
void foo() { BOOST_TRY { ... } BOOST_CATCH(const std::bad_alloc&) { ... BOOST_RETHROW } BOOST_CATCH(const std::exception& e) { ... } BOOST_CATCH_ALL { ... } }
If you refer to why BOOST_CATCH_END is needed in the original formulation, consider the following:
if(so) BOOST_TRY{ foo(); } BOOST_CATCH(const std::exception& e){ bar(); BOOST_RETHROW } else baz();
This, using your variation, expands to
if(so) if (true){ foo(); } else if (false){ bar(); } else baz();
which is equivalent to (note the braces)
if(so){ if (true){ foo(); } else if (false){ bar(); } else{ baz(); } }
which is clearly not the intention.
Yes I see. This is why I added BOOST_CAT_ALL, but the its use can not be forced and as your example shows can have dramatic effects. Thanks, Vicente
Emil Dotchevski <emildotchevski <at> gmail.com> writes:
On Tue, Mar 22, 2011 at 12:16 PM, Krzysztof Czainski <1czajnik <at> > >
What about boost/detail/no_exceptions_support.hpp? Could that file be moved to boost/exception for public use? I use it, but don't feel comfortable with it being in the detail directory.
This header is news to me. :) Maybe something like this could become a documented part of Boost Exception.
I don't understand why the macros defined in no_exceptions_support.hpp expand to if("") { } else if(!"") { } etc. in BOOST_NO_EXCEPTIONS builds. Expanding to if(true) { } else if(false) { } seems more appropriate to me.
I seem to remember that if(true) and similar triggered warnings (à la "condition is always true") in some compilers. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Emil Dotchevski wrote:
On Tue, Mar 22, 2011 at 1:38 AM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Emil Dotchevski wrote:
On Mon, Mar 21, 2011 at 6:39 PM, Robert Kawulak <robert.kawulak@gmail.com> wrote:
From Boost Users ML:
From: Hochhaus, Andrew I would like to use boost with BOOST_NO_EXCEPTIONS [1] and the g++ -fno-exceptions flag. However, it appears that some spots in boost library code:
a) throw exceptions with the "raw" throw keyword [instead of BOOST_THROW_EXCEPTION or boost::throw_exception] b) use try ... catch blocks without "#ifnef BOOST_NO_EXCEPTIONS" guards
Wouldn't it be a good idea to add checks for these to the inspect tool? Also, non-empty exception specifications are discouraged by Boost guidelines - should appropriate checks be added too?
+1
I don't think that Boost libraries are required to support non-conforming compilers or operation modes of compilers, therefore adding inspect check for a workaround for such non-comforming behaviour would be wrong, I think.
Why use BOOST_THROW_EXCEPTION to throw?
- Typically, there is no need to do anything else to support BOOST_NO_EXCEPTIONS builds;
- Enables boost::exception_ptr, so the exceptions you throw can be transported between threads;
- Enables boost::error_info, so users can attach stuff to exceptions.
- Enables better messages from boost::diagnostic_information.
I fail to see how the above refutes my statement. We don't have a requirement that Boost libraries work with non-conforming environment. Nor is it required that any Boost library uses Boost.Exception. Therefore, adding no-exceptions to inspect checks -- whose primary purpose is to beat authors whose libraries fail those checks -- would be wrong. -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40
On Wed, Mar 23, 2011 at 1:05 AM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Emil Dotchevski wrote:
On Tue, Mar 22, 2011 at 1:38 AM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Emil Dotchevski wrote:
On Mon, Mar 21, 2011 at 6:39 PM, Robert Kawulak <robert.kawulak@gmail.com> wrote:
From Boost Users ML:
From: Hochhaus, Andrew I would like to use boost with BOOST_NO_EXCEPTIONS [1] and the g++ -fno-exceptions flag. However, it appears that some spots in boost library code:
a) throw exceptions with the "raw" throw keyword [instead of BOOST_THROW_EXCEPTION or boost::throw_exception] b) use try ... catch blocks without "#ifnef BOOST_NO_EXCEPTIONS" guards
Wouldn't it be a good idea to add checks for these to the inspect tool? Also, non-empty exception specifications are discouraged by Boost guidelines - should appropriate checks be added too?
+1
I don't think that Boost libraries are required to support non-conforming compilers or operation modes of compilers, therefore adding inspect check for a workaround for such non-comforming behaviour would be wrong, I think.
Why use BOOST_THROW_EXCEPTION to throw?
- Typically, there is no need to do anything else to support BOOST_NO_EXCEPTIONS builds;
- Enables boost::exception_ptr, so the exceptions you throw can be transported between threads;
- Enables boost::error_info, so users can attach stuff to exceptions.
- Enables better messages from boost::diagnostic_information.
I fail to see how the above refutes my statement. We don't have a requirement that Boost libraries work with non-conforming environment. Nor is it required that any Boost library uses Boost.Exception.
The semantics of BOOST_THROW_EXCEPTION are such that typically, if a library uses it to throw, the library also supports BOOST_NO_EXCEPTION builds. My point was that there is no reason for a Boost library not to use BOOST_THROW_EXCEPTION to throw.
Therefore, adding no-exceptions to inspect checks -- whose primary purpose is to beat authors whose libraries fail those checks -- would be wrong.
AFAIK, the only builds authors are required to support are the ones in the release test, I'm not proposing to change that requirement. This is an issue of uniformity and usability. We don't require that libraries use BOOST_ASSERT to assert but using it makes Boost libraries more usable. It is the same with BOOST_THROW_EXCEPTION. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
From: Vladimir Prus I fail to see how the above refutes my statement. We don't have a requirement that Boost libraries work with non-conforming environment. Nor is it required that any Boost library uses Boost.Exception.
Therefore, adding no-exceptions to inspect checks -- whose primary purpose is to beat authors whose libraries fail those checks -- would be wrong.
I feel that there may be some misunderstanding regarding the motivation behind BOOST_THROW_EXCEPTION Inspect check in this thread. First of all, Inspect is for checking "official" Boost guidelines. BOOST_THROW_EXCEPTION is obviously not such a guideline yet. What I'm proposing is that: 1. we add using BOOST_THROW_EXCEPTION as a guideline, 2. we add a check for this guideline to Inspect. In the context of guidelines, preferring BOOST_THROW_EXCEPTION over plain throw is NOT about supporting BOOST_NO_EXEPTIONS platforms. Of course, if try/catch/throw are not used in the code, you get this ability for free as a bonus. That's nice too, but that's not the main point. The points are already explained by Emil and me: - automatic attachment of throw site information (file/line/function), letting you guess what went wrong at a glimpse without even needing to attach debugger in some cases, - enabling mechanism for attaching extra information via boost::error_info and building verbose error descriptions using this information by boost::diagnostic_information, - enabling transfer of exceptions between threads, - providing global customisation point of exception-throwing behaviour, just like BOOST_ASSERT does for the assert macro. Best regards, Robert
On Wed, Mar 23, 2011 at 4:57 PM, Robert Kawulak <robert.kawulak@gmail.com> wrote:
In the context of guidelines, preferring BOOST_THROW_EXCEPTION over plain throw is NOT about supporting BOOST_NO_EXEPTIONS platforms. Of course, if try/catch/throw are not used in the code, you get this ability for free as a bonus. That's nice too, but that's not the main point.
The points are already explained by Emil and me: - automatic attachment of throw site information (file/line/function), letting you guess what went wrong at a glimpse without even needing to attach debugger in some cases, - enabling mechanism for attaching extra information via boost::error_info and building verbose error descriptions using this information by boost::diagnostic_information, - enabling transfer of exceptions between threads, - providing global customisation point of exception-throwing behaviour, just like BOOST_ASSERT does for the assert macro.
In my mind it's exactly the other way around: the main point of BOOST_THROW_EXCEPTION is to support BOOST_NO_EXCEPTIONS builds, the other stuff is just a free bonus. I say this because BOOST_THROW_EXCEPTION simply captures __FILE__ and __LINE__, otherwise it just calls boost::throw_exception(). Historically, the *only* point of boost::throw_exception() was to support BOOST_NO_EXCEPTION builds. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
From: Emil Dotchevski In my mind it's exactly the other way around: the main point of BOOST_THROW_EXCEPTION is to support BOOST_NO_EXCEPTIONS builds, the other stuff is just a free bonus.
OK, but you're speaking about the motivation for development of BOOST_THROW_EXCEPTION. I'm speaking about the motivation to make using BOOST_THROW_EXCEPTION a guideline. Supporting non-conforming compilers is definitely not in the focus of Boost guidelines ("There is no requirement that a library run on C++ compilers which do not conform to the ISO standard.") Best regards, Robert
Message du 24/03/11 03:02 De : "Robert Kawulak" A : boost@lists.boost.org Copie à : Objet : Re: [boost] [inspect] exceptions (FW: [Boost-users] no exceptions)
From: Emil Dotchevski In my mind it's exactly the other way around: the main point of BOOST_THROW_EXCEPTION is to support BOOST_NO_EXCEPTIONS builds, the other stuff is just a free bonus.
OK, but you're speaking about the motivation for development of BOOST_THROW_EXCEPTION. I'm speaking about the motivation to make using BOOST_THROW_EXCEPTION a guideline. Supporting non-conforming compilers is definitely not in the focus of Boost guidelines ("There is no requirement that a library run on C++ compilers which do not conform to the ISO standard.")
Note that people working on embedded systems could be using a conforming compiler but they could decide to disable exceptions as the performances could be improved, let me say by 15%. 15% that they absolutely need. Best, Vicente
AMDG On 03/23/2011 07:32 PM, Vicente BOTET wrote:
OK, but you're speaking about the motivation for development of BOOST_THROW_EXCEPTION. I'm speaking about the motivation to make using BOOST_THROW_EXCEPTION a guideline. Supporting non-conforming compilers is definitely not in the focus of Boost guidelines ("There is no requirement that a library run on C++ compilers which do not conform to the ISO standard.") Note that people working on embedded systems could be using a conforming compiler but they could decide to disable exceptions as the performances could be improved, let me say by 15%. 15% that they absolutely need.
The fact that non-conformance is intentional does not make it conforming. In Christ, Steven Watanabe
At Tue, 22 Mar 2011 11:38:59 +0300, Vladimir Prus wrote:
Emil Dotchevski wrote:
On Mon, Mar 21, 2011 at 6:39 PM, Robert Kawulak <robert.kawulak@gmail.com> wrote:
From Boost Users ML:
From: Hochhaus, Andrew I would like to use boost with BOOST_NO_EXCEPTIONS [1] and the g++ -fno-exceptions flag. However, it appears that some spots in boost library code:
a) throw exceptions with the "raw" throw keyword [instead of BOOST_THROW_EXCEPTION or boost::throw_exception] b) use try ... catch blocks without "#ifnef BOOST_NO_EXCEPTIONS" guards
Wouldn't it be a good idea to add checks for these to the inspect tool? Also, non-empty exception specifications are discouraged by Boost guidelines - should appropriate checks be added too?
+1
I don't think that Boost libraries are required to support non-conforming compilers or operation modes of compilers, therefore adding inspect check for a workaround for such non-comforming behaviour would be wrong, I think.
Well... I was going to write this: I think we ought to establish something weaker than requirements but still official, like "portability best practices" or something, that would include making the adjustments needed to run in exception-free environments. but the more I think about it, the less clear I am on what that means. Would we be asking people to try to recover from out-of-memory and other exceptional conditions via some other mechanism when exceptions are disabled? That seems impractical to me. We could barely even use the standard library under those circumstances. What do people who turn off exceptions expect from their libraries? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Tue, Mar 22, 2011 at 11:37 PM, Dave Abrahams <dave@boostpro.com> wrote:
At Tue, 22 Mar 2011 11:38:59 +0300, Vladimir Prus wrote:
Emil Dotchevski wrote:
On Mon, Mar 21, 2011 at 6:39 PM, Robert Kawulak <robert.kawulak@gmail.com> wrote:
From Boost Users ML:
From: Hochhaus, Andrew I would like to use boost with BOOST_NO_EXCEPTIONS [1] and the g++ -fno-exceptions flag. However, it appears that some spots in boost library code:
a) throw exceptions with the "raw" throw keyword [instead of BOOST_THROW_EXCEPTION or boost::throw_exception] b) use try ... catch blocks without "#ifnef BOOST_NO_EXCEPTIONS" guards
Wouldn't it be a good idea to add checks for these to the inspect tool? Also, non-empty exception specifications are discouraged by Boost guidelines - should appropriate checks be added too?
+1
I don't think that Boost libraries are required to support non-conforming compilers or operation modes of compilers, therefore adding inspect check for a workaround for such non-comforming behaviour would be wrong, I think.
Well... I was going to write this:
I think we ought to establish something weaker than requirements but still official, like "portability best practices" or something, that would include making the adjustments needed to run in exception-free environments.
but the more I think about it, the less clear I am on what that means. Would we be asking people to try to recover from out-of-memory and other exceptional conditions via some other mechanism when exceptions are disabled? That seems impractical to me. We could barely even use the standard library under those circumstances. What do people who turn off exceptions expect from their libraries?
What they expect is beyond our control, but this is what we require: http://www.boost.org/doc/libs/release/libs/exception/doc/throw_exception.htm.... Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Wed, Mar 23, 2011 at 12:07 AM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
On Tue, Mar 22, 2011 at 11:37 PM, Dave Abrahams <dave@boostpro.com> wrote:
At Tue, 22 Mar 2011 11:38:59 +0300, Vladimir Prus wrote:
Emil Dotchevski wrote:
On Mon, Mar 21, 2011 at 6:39 PM, Robert Kawulak <robert.kawulak@gmail.com> wrote:
From Boost Users ML:
From: Hochhaus, Andrew I would like to use boost with BOOST_NO_EXCEPTIONS [1] and the g++ -fno-exceptions flag. However, it appears that some spots in boost library code:
a) throw exceptions with the "raw" throw keyword [instead of BOOST_THROW_EXCEPTION or boost::throw_exception] b) use try ... catch blocks without "#ifnef BOOST_NO_EXCEPTIONS" guards
Wouldn't it be a good idea to add checks for these to the inspect tool? Also, non-empty exception specifications are discouraged by Boost guidelines - should appropriate checks be added too?
+1
I don't think that Boost libraries are required to support non-conforming compilers or operation modes of compilers, therefore adding inspect check for a workaround for such non-comforming behaviour would be wrong, I think.
Well... I was going to write this:
I think we ought to establish something weaker than requirements but still official, like "portability best practices" or something, that would include making the adjustments needed to run in exception-free environments.
but the more I think about it, the less clear I am on what that means. Would we be asking people to try to recover from out-of-memory and other exceptional conditions via some other mechanism when exceptions are disabled? That seems impractical to me. We could barely even use the standard library under those circumstances. What do people who turn off exceptions expect from their libraries?
What they expect is beyond our control, but this is what we require: http://www.boost.org/doc/libs/release/libs/exception/doc/throw_exception.htm....
That does not look like a requirement on Boost library authors to me, so it makes me wonder about its relevance. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
I use exceptions, but I'm also sympathetic to those who can't use or don't want them. I'm skeptical that all libraries can or should be designed to work without exceptions. Would it be possible to simply specify which libraries support exception-free operation, in a fashion similar to how certain libraries are called out as header-only? There's a potentially further distinction between libraries which propagate exceptions to the caller and those which only require them internally. Whatever arguments there are for using BOOST_THROW_EXCEPTION() vs. throw, that seems a somewhat independent matter. Simply making this substitution does not guarantee that the library will work properly with exceptions disabled, and there might be legitimate reasons for libraries not designed to operate without exceptions use throw. IMO, separating these issues & potentially litigating them on a case-by-case basis could make this more tractable. Matt ________________________________ From: boost-bounces@lists.boost.org on behalf of Dave Abrahams Sent: Wed 3/23/2011 12:55 PM To: boost@lists.boost.org Subject: Re: [boost] [inspect] exceptions (FW: [Boost-users] no exceptions) On Wed, Mar 23, 2011 at 12:07 AM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
On Tue, Mar 22, 2011 at 11:37 PM, Dave Abrahams <dave@boostpro.com> wrote:
At Tue, 22 Mar 2011 11:38:59 +0300, Vladimir Prus wrote:
but the more I think about it, the less clear I am on what that means. Would we be asking people to try to recover from out-of-memory and other exceptional conditions via some other mechanism when exceptions are disabled? That seems impractical to me. We could barely even use the standard library under those circumstances. What do people who turn off exceptions expect from their libraries?
What they expect is beyond our control, but this is what we require: http://www.boost.org/doc/libs/release/libs/exception/doc/throw_exception.htm....
That does not look like a requirement on Boost library authors to me, so it makes me wonder about its relevance.
On Wed, Mar 23, 2011 at 1:47 PM, Gruenke, Matt <mgruenke@tycoint.com> wrote:
Whatever arguments there are for using BOOST_THROW_EXCEPTION() vs. throw, that seems a somewhat independent matter. Simply making this substitution does not guarantee that the library will work properly with exceptions disabled,
It is not independent matter because that is exactly what BOOST_THROW_EXCEPTION guarantees, except when the library contains try..catch or rethrows using throw without arguments, which are rare cases. I agree that going the extra mile to workaround those additional cases is usually unreasonable.
and there might be legitimate reasons for libraries not designed to operate without exceptions use throw.
Aside from ignorance, one reason to prefer throw over BOOST_THROW_EXCEPTION is to ensure that BOOST_NO_EXCEPTONS builds don't work, and that the exception object can't be transported between threads. :) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
At Wed, 23 Mar 2011 14:29:20 -0700, Emil Dotchevski wrote:
On Wed, Mar 23, 2011 at 1:47 PM, Gruenke, Matt <mgruenke@tycoint.com> wrote:
Whatever arguments there are for using BOOST_THROW_EXCEPTION() vs. throw, that seems a somewhat independent matter. Simply making this substitution does not guarantee that the library will work properly with exceptions disabled,
It is not independent matter because that is exactly what BOOST_THROW_EXCEPTION guarantees, except when the library contains try..catch or rethrows using throw without arguments, which are rare cases. I agree that going the extra mile to workaround those additional cases is usually unreasonable.
I suppose that might be true, depending on your definition of "work properly." There's no such thing as "working properly without exceptions" if the library was coded for use with exceptions and you really need a recoverable response to, say, resource exhaustion. That said, "libraries should generally use BOOST_THROW_EXCEPTION" is a good rule for Boost, and I wouldn't mind having something like it in the inspect tests, provided that libraries with a legitimate reason not to use it can be registered as exceptions to the rule. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Thu, Mar 24, 2011 at 9:34 AM, Dave Abrahams <dave@boostpro.com> wrote:
At Wed, 23 Mar 2011 14:29:20 -0700, Emil Dotchevski wrote:
On Wed, Mar 23, 2011 at 1:47 PM, Gruenke, Matt <mgruenke@tycoint.com> wrote:
Whatever arguments there are for using BOOST_THROW_EXCEPTION() vs. throw, that seems a somewhat independent matter. Simply making this substitution does not guarantee that the library will work properly with exceptions disabled,
It is not independent matter because that is exactly what BOOST_THROW_EXCEPTION guarantees, except when the library contains try..catch or rethrows using throw without arguments, which are rare cases. I agree that going the extra mile to workaround those additional cases is usually unreasonable.
I suppose that might be true, depending on your definition of "work properly." There's no such thing as "working properly without exceptions" if the library was coded for use with exceptions and you really need a recoverable response to, say, resource exhaustion.
Yes, if the program needs recoverable response, then BOOST_THROW_EXCEPTION is not going to work, and it is not at all desirable to require that libraries provide an alternative mechanism. However, this also means that BOOST_THROW_EXCEPTION will work just fine in other scenarios: 1) When the program can deterministically avoid using operations that throw. Example: using weak_ptr::lock instead of directly constructing a shared_ptr from weak_ptr (which may throw.) 2) When abort() is a reasonable response to failure. Example: in video games, it is typically OK to abort on file open or read failure, on failure to initialize the graphics system, etc.
That said, "libraries should generally use BOOST_THROW_EXCEPTION" is a good rule for Boost, and I wouldn't mind having something like it in the inspect tests, provided that libraries with a legitimate reason not to use it can be registered as exceptions to the rule.
Maybe I'm missing something but what is an example of such a legitimate reason? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
At Thu, 24 Mar 2011 11:27:23 -0700, Emil Dotchevski wrote:
That said, "libraries should generally use BOOST_THROW_EXCEPTION" is a good rule for Boost, and I wouldn't mind having something like it in the inspect tests, provided that libraries with a legitimate reason not to use it can be registered as exceptions to the rule.
Maybe I'm missing something but what is an example of such a legitimate reason?
For example, "it buys nothing, because the library can't really work as coded without exception support." Such is the case for Boost.Python, I believe. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Thu, Mar 24, 2011 at 4:50 PM, Dave Abrahams <dave@boostpro.com> wrote:
At Thu, 24 Mar 2011 11:27:23 -0700, Emil Dotchevski wrote:
That said, "libraries should generally use BOOST_THROW_EXCEPTION" is a good rule for Boost, and I wouldn't mind having something like it in the inspect tests, provided that libraries with a legitimate reason not to use it can be registered as exceptions to the rule.
Maybe I'm missing something but what is an example of such a legitimate reason?
For example, "it buys nothing, because the library can't really work as coded without exception support." Such is the case for Boost.Python, I believe.
Whether it makes the library useful in BOOST_NO_EXCEPTIONS builds is best left for the user of the library to decide. At any rate, you gain nothing from not using BOOST_THROW_EXCEPTION. Besides, even if the library remains useless in BOOST_NO_EXCEPTIONS builds, I wouldn't say that BOOST_THROW_EXCEPTION buys nothing. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
At Thu, 24 Mar 2011 17:49:55 -0700, Emil Dotchevski wrote:
On Thu, Mar 24, 2011 at 4:50 PM, Dave Abrahams <dave@boostpro.com> wrote:
At Thu, 24 Mar 2011 11:27:23 -0700, Emil Dotchevski wrote:
That said, "libraries should generally use BOOST_THROW_EXCEPTION" is a good rule for Boost, and I wouldn't mind having something like it in the inspect tests, provided that libraries with a legitimate reason not to use it can be registered as exceptions to the rule.
Maybe I'm missing something but what is an example of such a legitimate reason?
For example, "it buys nothing, because the library can't really work as coded without exception support." Such is the case for Boost.Python, I believe.
Whether it makes the library useful in BOOST_NO_EXCEPTIONS builds is best left for the user of the library to decide.
No, really. Python throws exceptions as a matter of course (e.g. loop termination). These get translated into C++ exceptions.
At any rate, you gain nothing from not using BOOST_THROW_EXCEPTION.
One fewer dependencies? Not that I really care; I'd be happy to use it. It's just that it's also very easy for me to imagine that some libraries might be exceptions to the rule.
Besides, even if the library remains useless in BOOST_NO_EXCEPTIONS builds, I wouldn't say that BOOST_THROW_EXCEPTION buys nothing.
What does it buy in this case? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Thu, Mar 24, 2011 at 6:04 PM, Dave Abrahams <dave@boostpro.com> wrote:
At Thu, 24 Mar 2011 17:49:55 -0700, Emil Dotchevski wrote:
On Thu, Mar 24, 2011 at 4:50 PM, Dave Abrahams <dave@boostpro.com> wrote:
At Thu, 24 Mar 2011 11:27:23 -0700, Emil Dotchevski wrote:
That said, "libraries should generally use BOOST_THROW_EXCEPTION" is a good rule for Boost, and I wouldn't mind having something like it in the inspect tests, provided that libraries with a legitimate reason not to use it can be registered as exceptions to the rule.
Maybe I'm missing something but what is an example of such a legitimate reason?
For example, "it buys nothing, because the library can't really work as coded without exception support." Such is the case for Boost.Python, I believe.
Whether it makes the library useful in BOOST_NO_EXCEPTIONS builds is best left for the user of the library to decide.
No, really. Python throws exceptions as a matter of course (e.g. loop termination). These get translated into C++ exceptions.
Maybe I don't use for loops in my python scripts then. Regardless how dumb this is, as a matter of principle the library shouldn't care exactly how the user program satisfies the requirements of BOOST_THROW_EXCEPTION.
At any rate, you gain nothing from not using BOOST_THROW_EXCEPTION.
One fewer dependencies? Not that I really care; I'd be happy to use it. It's just that it's also very easy for me to imagine that some libraries might be exceptions to the rule.
You have a point, but consider that boost/throw_exception.hpp includes boost/config.hpp, adding only about 500 lines of C++.
Besides, even if the library remains useless in BOOST_NO_EXCEPTIONS builds, I wouldn't say that BOOST_THROW_EXCEPTION buys nothing.
What does it buy in this case?
- Enables transporting of exceptions between threads - Enables transporting of arbitrary data in exception objects - Enables boost::diagnostic_information to return a better message (double-clicking the message in Visual Studio and other editors' log window opens the throw location.) It seems unreasonable to consciously take these away from the user. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
At Thu, 24 Mar 2011 20:01:33 -0700, Emil Dotchevski wrote:
On Thu, Mar 24, 2011 at 6:04 PM, Dave Abrahams <dave@boostpro.com> wrote:
At Thu, 24 Mar 2011 17:49:55 -0700, Emil Dotchevski wrote:
Besides, even if the library remains useless in BOOST_NO_EXCEPTIONS builds, I wouldn't say that BOOST_THROW_EXCEPTION buys nothing.
What does it buy in this case?
- Enables transporting of exceptions between threads
- Enables transporting of arbitrary data in exception objects
- Enables boost::diagnostic_information to return a better message (double-clicking the message in Visual Studio and other editors' log window opens the throw location.)
It seems unreasonable to consciously take these away from the user.
Point taken. +1 for just making it policy, then. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
At Thu 3/24/2011 9:04 PM, Dave Abrahams wrote: At Thu, 24 Mar 2011 17:49:55 -0700, Emil Dotchevski wrote:
On Thu, Mar 24, 2011 at 4:50 PM, Dave Abrahams <dave@boostpro.com> wrote:
At Thu, 24 Mar 2011 11:27:23 -0700, Emil Dotchevski wrote:
For example, "it buys nothing, because the library can't really work as coded without exception support." Such is the case for Boost.Python, I believe.
Whether it makes the library useful in BOOST_NO_EXCEPTIONS builds is best left for the user of the library to decide.
No, really. Python throws exceptions as a matter of course (e.g. loop termination). These get translated into C++ exceptions.
I really have a problem with the suggestion that using BOOST_NO_EXCEPTIONS should be so risky. IMO, if a library isn't designed to work with without exceptions, then it should be automatically disabled. If the user really wants to take its chances, then it can try to force the library to build. Users operating in exception-restricted circumstances deserve no fewer promises than the rest of us.
Besides, even if the library remains useless in BOOST_NO_EXCEPTIONS builds, I wouldn't say that BOOST_THROW_EXCEPTION buys nothing.
What does it buy in this case?
I'll volunteer an answer to a different question: "what does it cost?" I did a little bit of performance testing and found BOOST_THROW_EXCEPTION to add about 45% overhead (CPU: Intel Xeon X5570; compiler: gcc-4.2.3; optimization: -O2) vs straight 'throw' of simple std::exception-derived class. So, it's not exactly free. That said, neither is blazingly fast. The reason I thought use of BOOST_THROW_EXCEPTION could be litigated on a per-library basis is that I can see someone not wanting to pay for that overhead (or perhaps being forced to accept some other side-effect) for an exception that's entirely internal to a library. But in the absence of such a reason, I'd agree that it should be strongly encouraged. To me, this thread feels a little like a witchhunt. When used judiciously, exceptions can significantly simplify interfaces and the code which uses them. I hope not to see them made optional in any library where doing so would necessitate that interfaces or usability be compromised. So, while I would like to see Boost libraries accommodate those in exception-restricted circumstances, I also don't want to see them get watered down, as a result. Matt
On Thu, Mar 24, 2011 at 8:03 PM, Gruenke, Matt <mgruenke@tycoint.com> wrote:
I did a little bit of performance testing and found BOOST_THROW_EXCEPTION to add about 45% overhead (CPU: Intel Xeon X5570; compiler: gcc-4.2.3; optimization: -O2) vs straight 'throw' of simple std::exception-derived class. So, it's not exactly free. That said, neither is blazingly fast.
Could you clarify, what do you mean by overhead? Speed? Speed of throwing an exception? Speed of catching an exception? Code size? Compilation time? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Thu, Mar 24, 2011 at 8:03 PM, Gruenke, Matt <mgruenke@tycoint.com> wrote:
I did a little bit of performance testing and found BOOST_THROW_EXCEPTION to add about 45% overhead (CPU: Intel Xeon X5570; compiler: gcc-4.2.3; optimization: -O2) vs straight 'throw' of simple std::exception-derived class. So, it's not exactly free. That said, neither is blazingly fast.
Could you clarify, what do you mean by overhead? Speed? Speed of throwing an exception? Speed of catching an exception? Code size? Compilation time?
I think a different question is worth asking -- did you measure any of above? - Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40
On Fri, Mar 25, 2011 at 12:17 AM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Emil Dotchevski wrote:
On Thu, Mar 24, 2011 at 8:03 PM, Gruenke, Matt <mgruenke@tycoint.com> wrote:
I did a little bit of performance testing and found BOOST_THROW_EXCEPTION to add about 45% overhead (CPU: Intel Xeon X5570; compiler: gcc-4.2.3; optimization: -O2) vs straight 'throw' of simple std::exception-derived class. So, it's not exactly free. That said, neither is blazingly fast.
Could you clarify, what do you mean by overhead? Speed? Speed of throwing an exception? Speed of catching an exception? Code size? Compilation time?
I think a different question is worth asking -- did you measure any of above?
No, I did not measure the overhead of throwing and catching class A deriving from class B and std::exception vs. throwing and catching class A deriving from std::exception only. Honestly, I've never measured the speed of throwing and catching any exceptions on any platform -- I tend to focus on whatever the profiler points me to. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Fri 3/25/2011 2:54 PM, Emil Dotchevski wrote:
On Fri, Mar 25, 2011 at 12:17 AM, Vladimir Prus wrote:
I think a different question is worth asking -- did you measure any of above?
No, I did not measure the overhead of throwing and catching class A deriving from class B and std::exception vs. throwing and catching class A deriving from std::exception only.
AFAIK, exceptions aren't exactly cheap, no matter what. Therefore, as long as BOOST_THROW_EXCEPTION() doesn't increase the cost by like an order of magnitude, I wouldn't much mind.
Honestly, I've never measured the speed of throwing and catching any exceptions on any platform -- I tend to focus on whatever the profiler points me to.
It's when you start insisting that it must be used everywhere that something like 50% overhead can start to be a problem. It just might be that exceptions are a hot spot, in a particular design or context (maybe Boost.Python is a good example?). If you force people to use BOOST_THROW_EXCEPTION() and it's not essentially free, then you're limiting the optimizations they can do. And if some of those are cases where no benefit can be derived from its usage (i.e. because they're internal exceptions that are always caught and the code won't work properly when compiled without them), then such a policy starts to look questionable. I haven't seen anyone come out against BOOST_THROW_EXCEPTION(), in the general case. Clearly, it's provides useful benefits to users and should be encouraged - even with the help of automated tools like inspect. I'm just not convinced that an absolute requirement would be a good thing, especially when tools can otherwise still potentially catch most unintentional omissions. Matt
On Fri, Mar 25, 2011 at 3:22 PM, Gruenke, Matt <mgruenke@tycoint.com> wrote:
On Fri 3/25/2011 2:54 PM, Emil Dotchevski wrote:
Honestly, I've never measured the speed of throwing and catching any exceptions on any platform -- I tend to focus on whatever the profiler points me to. It's when you start insisting that it must be used everywhere that something like 50% overhead can start to be a problem. It just might be that exceptions are a hot spot, in a particular design or context (maybe Boost.Python is a good example?).
First, let's get on the same page about the nature of the cost of BOOST_THROW_EXCEPTION: - It adds ~500 lines of C++ code, increasing your compile times. Compare this to something as basic as boost/config.hpp, which preprocesses to ~47000 lines on my system. - If you wanted to throw T, it throws U:T,B instead. Even if this makes catch(T&) slower, catching exception objects by a base type is quite common. Second, consider that this is only the default behavior. All this functionality disappears if you #define BOOST_EXCEPTION_DISABLE. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Fri 3/25/2011 8:51 PM, Emil Dotchevski wrote:
First, let's get on the same page about the nature of the cost of BOOST_THROW_EXCEPTION:
- It adds ~500 lines of C++ code, increasing your compile times. Compare this to something as basic as boost/config.hpp, which preprocesses to ~47000 lines on my system.
What does that have to do with anything? I mean, depending on what they contain, 500 lines is certainly enough that they *could* have a major effect on code size or compile times, but I didn't attempt to measure that or make any claims along those lines. What I did measure is runtime CPU overhead in a simple throw/catch scenario. The impact BOOST_THROW_EXCEPTION does or doesn't have on compile time and code size doesn't change that.
Second, consider that this is only the default behavior. All this functionality disappears if you #define BOOST_EXCEPTION_DISABLE.
Huh? But that changes the behavior of the code, breaking it in places that depend on exceptions. I no longer understand where this exchange is going and, not being a decision-maker, it's not clear to me whether/how I can help move this issue to resolution. I presented a concern I had about a proposed change and the findings from my attempts to quantify one such scenario. I can clean up & submit my test program (a tiny thing, really), if others are having difficulty reproducing my results. Matt
On Fri, Mar 25, 2011 at 6:58 PM, Gruenke, Matt <mgruenke@tycoint.com> wrote:
On Fri 3/25/2011 8:51 PM, Emil Dotchevski wrote:
First, let's get on the same page about the nature of the cost of BOOST_THROW_EXCEPTION:
- It adds ~500 lines of C++ code, increasing your compile times. Compare this to something as basic as boost/config.hpp, which preprocesses to ~47000 lines on my system.
What does that have to do with anything?
This has to do with effect of BOOST_THROW_EXCEPTION on the time it takes to compile your program. I count that as cost.
Second, consider that this is only the default behavior. All this functionality disappears if you #define BOOST_EXCEPTION_DISABLE.
Huh? But that changes the behavior of the code, breaking it in places that depend on exceptions.
You seem to be confusing BOOST_NO_EXCEPTIONS with BOOST_EXCEPTION_DISABLE. Both change the behavior of BOOST_THROW_EXCEPTION: - BOOST_NO_EXCEPTIONS makes it call a user-defined function instead of throwing - BOOST_EXCEPTION_DISABLE turns it into a simple throw (e.g. no cost) except if BOOST_NO_EXCEPTIONS is defined, which takes precedence. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Fri 3/25/2011 10:33 PM, Emil Dotchevski wrote:
What does that have to do with anything?
This has to do with effect of BOOST_THROW_EXCEPTION on the time it takes to compile your program. I count that as cost.
That is true. I was under the impression that it you mentioned it to downplay the runtime cost. I apologize for my misunderstanding. I support any analysis of its various costs, as it lets users and (for now) library authors make a more informed choice about whether and how to use it.
Second, consider that this is only the default behavior. All this functionality disappears if you #define BOOST_EXCEPTION_DISABLE.
Huh? But that changes the behavior of the code, breaking it in places that depend on exceptions.
You seem to be confusing BOOST_NO_EXCEPTIONS with BOOST_EXCEPTION_DISABLE. Both change the behavior of BOOST_THROW_EXCEPTION:
Yes, you are correct. The macros have a clumsiness, though. If I have a library with both internal and external exceptions, it's only practical to enable or disable the features of BOOST_THROW_EXCEPTION() on a per-source file basis. Also, if a library with only internal exceptions uses BOOST_THROW_EXCEPTION() along with BOOST_EXCEPTION_DISABLE, then what benefit does that provide over just telling inspect to disregard use of 'throw' in the library (or certain parts of it)? Matt
On Fri 3/25/2011 12:58 AM, Emil Dotchevski wrote:
On Thu, Mar 24, 2011 at 8:03 PM, Gruenke, Matt <mgruenke@tycoint.com> wrote:
I did a little bit of performance testing and found BOOST_THROW_EXCEPTION to add about 45% overhead (CPU: Intel Xeon X5570; compiler: gcc-4.2.3; optimization: -O2) vs straight 'throw' of simple std::exception-derived class. So, it's not exactly free. That said, neither is blazingly fast.
Could you clarify, what do you mean by overhead? Speed? Speed of throwing an exception? Speed of catching an exception? Code size? Compilation time?
I was talking about the CPU overhead of throwing + catching an exception. The time was essentially all userspace. If you recall, my point was that library-internal exceptions are an example of a case where there's no benefit to using the wrapper. If the wrapper had no cost and imposed no other constraints, then there wouldn't be an argument against requiring it. So, what I set out to do was to determine whether it does add significant overhead. We already know that it imposes other requirements and constraints. BTW, I did not compare against an exception not derived from std::exception, yet it's quite plausible that an internal exception might not otherwise do that. That might reveal even more overhead. Matt
At Wed, 23 Mar 2011 16:47:41 -0400, Gruenke, Matt wrote:
I use exceptions, but I'm also sympathetic to those who can't use or don't want them. I'm skeptical that all libraries can or should be designed to work without exceptions.
+1
Would it be possible to simply specify which libraries support exception-free operation, in a fashion similar to how certain libraries are called out as header-only?
+1
There's a potentially further distinction between libraries which propagate exceptions to the caller and those which only require them internally.
-1. Until there's a demonstrated need, let's not overspecify -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Message du 23/03/11 21:49 De : "Gruenke, Matt" A : boost@lists.boost.org Copie à : Objet : Re: [boost] [inspect] exceptions (FW: [Boost-users] no exceptions)
I use exceptions, but I'm also sympathetic to those who can't use or don't want them. I'm skeptical that all libraries can or should be designed to work without exceptions.
Would it be possible to simply specify which libraries support exception-free operation, in a fashion similar to how certain libraries are called out as header-only? There's a potentially further distinction between libraries which propagate exceptions to the caller and those which only require them internally.
Whatever arguments there are for using BOOST_THROW_EXCEPTION() vs. throw, that seems a somewhat independent matter. Simply making this substitution does not guarantee that the library will work properly with exceptions disabled, and there might be legitimate reasons for libraries not designed to operate without exceptions use throw.
IMO, separating these issues & potentially litigating them on a case-by-case basis could make this more tractable.
Matt
Hi, I agree that boost libraries are required to work without exceptions or rtti enabled, but I'm sure that people working on the embedded domains would be grateful if they could use some parts of Boost also. They use to use C++ without exceptions and without RTTI as this features are not deterministic. I think that it will be a good thing if we can label the libraries that pass on these configurations. The big question stay the one Dave made: What do they do on the throw_exception function? I think that most of them just are happy by aborting and restart, but maybe some people more experienced in this domain could share their experiences. Note also the Beman proposal to pass an error code as argument to mean don't throw, so people working on these environments can use this specific interface. Of course this new parameter add a burden on the author side. Thinking a little bit more on this, the current implementation of Boost.Chrono provides such interfaces replacing exceptions by error codes, but doesn't ensures that no-exceptions are used. Best, Vicente
Message du 22/03/11 02:40 De : "Robert Kawulak" A : boost@lists.boost.org Copie à : Objet : [boost] [inspect] exceptions (FW: [Boost-users] no exceptions)
From Boost Users ML:
From: Hochhaus, Andrew I would like to use boost with BOOST_NO_EXCEPTIONS [1] and the g++ -fno-exceptions flag. However, it appears that some spots in boost library code:
a) throw exceptions with the "raw" throw keyword [instead of BOOST_THROW_EXCEPTION or boost::throw_exception] b) use try ... catch blocks without "#ifnef BOOST_NO_EXCEPTIONS" guards
Wouldn't it be a good idea to add checks for these to the inspect tool? Also, non-empty exception specifications are discouraged by Boost guidelines - should appropriate checks be added too?
Hi, I guess that the best we can do is to build the lib and the tests with exceptions disabled. No need to update the inspect tool. The inspect tool is there to check things that can not be tested in an easy way with the compiler. Take also in account that inspect is not there to check for guidelines, but for rules. Best, Vicente
From: Vicente BOTET I guess that the best we can do is to build the lib and the tests with exceptions disabled. No need to update the inspect tool.
Why bother with building everything in various configurations specifically to solve this problem when there's already a tool created and used regularly to check for such things?
The inspect tool is there to check things that can not be tested in an easy way with the compiler.
This seems ad-hoc to me. Inspect is there to automatically check for guidelines violations. Whether it is possible to detect the violations manually with a specifically configured compiler is not relevant.
Take also in account that inspect is not there to check for guidelines, but for rules.
Apart from the fact that rule and guideline are synonyms in this context, the docs for Boost.Inspect explicitly say about GUIDELINE violations and "common problems". Using throw instead of BOOST_THROW_EXCEPTION or using non-empty exception specifications is a guideline violation. The latter is already mentioned in "Boost Library Requirements and Guidelines"; the former is not, but it ought to be. Best regards, Robert
Message du 22/03/11 23:47 De : "Robert Kawulak" A : boost@lists.boost.org Copie à : Objet : Re: [boost] [inspect] exceptions (FW: [Boost-users] no exceptions)
From: Vicente BOTET I guess that the best we can do is to build the lib and the tests with exceptions disabled. No need to update the inspect tool.
Why bother with building everything in various configurations specifically to solve this problem when there's already a tool created and used regularly to check for such things?
You are right, the compiler will check only some parts of the code.
The inspect tool is there to check things that can not be tested in an easy way with the compiler.
This seems ad-hoc to me. Inspect is there to automatically check for guidelines violations. Whether it is possible to detect the violations manually with a specifically configured compiler is not relevant.
I guess that people will not make any effort to include in the inspection tool things that can be obtained by the compiler, but maybe you will.
Take also in account that inspect is not there to check for guidelines, but for rules.
Apart from the fact that rule and guideline are synonyms in this context, the docs for Boost.Inspect explicitly say about GUIDELINE violations and "common problems". Using throw instead of BOOST_THROW_EXCEPTION or using non-empty exception specifications is a guideline violation. The latter is already mentioned in "Boost Library Requirements and Guidelines"; the former is not, but it ought to be.
Take a look at the thing inspect is managing: Options: R -license R -copyright R -crlf ? -end R -link ? -path_name R -tab R -ascii R -apple_macro R -assert_macro R -minmax G -unnamed Most of them are things that the compiler can nor check and the one the compiler can check are very easy to implement. Except -unamed that I think is a guideline, the others are rules (I don't know what -end and -path_name checks). BTW, where the checks are documented? Please, note that I'm not against we add more check to inspect, but note that the value should outweigh the effort. If the test consist simply to check some keywords this seems simple. Is it to check the direct usage of throw, throws, try and catch? BTW, how many libraries build without exception support now, how many can run their tests? Best, Vicente
On 22 March 2011 23:27, Vicente BOTET <vicente.botet@wanadoo.fr> wrote:
Please, note that I'm not against we add more check to inspect
I'm vaguely against adding more inspection checks. We keep adding new checks and not fixing the problems they report. The more errors in the report that go unfixed, the more irrelevant it seems.
participants (11)
-
Daniel James -
Dave Abrahams -
Emil Dotchevski -
Gruenke, Matt -
Joaquin M Lopez Munoz -
Krzysztof Czainski -
Peter Dimov -
Robert Kawulak -
Steven Watanabe -
Vicente BOTET -
Vladimir Prus