Re: [boost] 5 Observations - My experience with the boost libraries

Subject: Re: [boost] 5 Observations - My experience with the boost libraries
From: Nicholas Howe (nicholas.howe_at_[hidden])
Date: 2010-03-28 13:45:05

Of course, I didn't consider the problem of exception specifications.  You'd
have to do something fancy to work around that.
Nick

On Sun, Mar 28, 2010 at 1:38 PM, Nicholas Howe <nicholas.howe_at_[hidden]>wrote:

> On Thu, Mar 25, 2010 at 6:58 PM, Tom Brinkman <reportbase2007_at_[hidden]>wrote:
>
>> 1) Boost uses exceptions.
>>
>
> I'm a game programmer.  I've worked at companies that disable exceptions.
>  One advantage of exceptions is that when they occur, the stack is unwound
> and object destructors are executed.  Another is that higher-level code is
> given an opportunity to recover from the exceptional condition.  If you
> don't care about either of these things, it might be acceptable for your
> program to terminate at any point where it would normally throw an
> exception.  Assuming your C++ implementation already terminates execution or
> otherwise behaves acceptably when features like std::operator new
> and reference dynamic_cast fail with exceptions disabled, I think you could
> achieve that with Boost using the preprocessor as shown below.
>
> #ifndef THROW_H
> #define THROW_H
>
> #include <cstdlib>
>
> struct Throw
> {
> };
>
> template< class T >
> inline void operator <<( Throw &, T const & )
> {
> std::exit( EXIT_FAILURE );
> }
>
> #define throw Throw() <<
>
> #endif
>
> You would include "Throw.h" before any headers that throw exceptions,
> perhaps using a compiler's force-include feature.  You could compile the
> non-header-only Boost libraries with this, too.  You could overload operator
> << to do different things with different exceptions, such as reporting the
> error in some fashion, or using platform specific code to detect if a
> debugger is attached and break if so.  This would also have the advantage
> that it would to some extent allow your C++ programmers to use exception
> semantics in their own code.
>
> If you come across cases where you don't want to terminate, and you're very
> clever and lucky, you might be able to make operator << translate the
> exception into a return value for the function.  This would be difficult
> because the same exception could be thrown by functions with different
> return value types.  You could return a Throw & from operator << and add
> conversion operators to Throw to make it turn into whatever the function
> wants.  However, it would be difficult to know what an appropriate return
> value would be.
>
> I think this simple header could allow Boost to be used in an environment
> that frowns on exceptions without any changes to Boost.  Of course, I
> haven't tried any of it.
> Nick
>
>