Re: [boost] Google SoC 2007 Big Integer project

From: Marco (mrcekets_at_[hidden])
Date: 2007-03-23 18:11:34

On Fri, 23 Mar 2007 19:08:03 +0100, Martin Bonner  
<Martin.Bonner_at_[hidden]> wrote:

> John Maddock wrote:
>
>> Mathias Gaunard wrote:
>>> Marco wrote:
>>>
>>>> (4) decide if we have to use exception handling C++ constructs for
>>>> arithmetic exceptions ( divide by zero, etc) or simply abort the
>>>> program; this is essentially a matter of performance;
>>>
>>> I didn't know aborting the program was more efficient than throwing an
>>> exception.
>>
>> It's not.  Or at least efficiency is irrelevant once the program is  
>> dead :-)
>>
>>> Why not just invoke undefined behaviour if that allows the best
>>> efficiency?
>>
>> Why not throw an exception?  Any overhead only occurs when an error has
>> actually happened, not on every operation.
> Not quite.  See below.
>> Or even better:
>>
>> if(error_condition)
> That is where the potential for additional overhead occurs.  Now, how  
> /serious/ it is, is an /entirely/ different matter.  Obviously, it  
> depends how much work it takes to calculate "error_condition", and how  
> tight a loop we are in.
>>    customisable_error_handler(information_about_error);
>>
>> And give the user a chance to decide what happens.

Sorry, maybe I don't succeed in explaining my ideas in english clearly.
What I was asking myself it was if the use of exception handling can imply  
a possible overhead.
After reading all your replies I realize that there is no need to use  
try/catch blocks but simply if-then instructions. The overhead problem is  
moved outside of the library; it is the library user to take a decision if  
he want to catch or not an exception. In this way it's possible for the  
user implement an ad hoc handle to manage the exception (nevertheless the  
library could also include a default sensible handle that the user can  
utilize if he finds that the handle is adequate).

The other alternative is no error handling at all (J. Maddock) that is the  
library has some undefined bahaviours (M. Gaunard).
Anyway to check a denominator it's not a serious overhead compared to the  
complexity of multi precision algorithms, and it seems to me that we can  
say the same for the other aritmethic exceptions, so the first solution  
seems better.

Regards, Marco

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/