Re: [boost] Google SoC 2007 Big Integer project

From: Hugh Wimberly (hugh.wimberly_at_[hidden])
Date: 2007-03-23 20:04:08

>
> > I could be way off base here, but I assumed the question related to the
> use
> > of try/catch blocks, which are very expensive
>
> What is that claim based on?
> The old myth saying exceptions are slower than return values, while it's
> actually the opposite?

Hmm. The last time I cared about efficiency of exception handling, I was
programming in C#, which takes a severe performance hit every time it enters
a try block. My cursory research backs you up, that the performance hit in
C++ is fairly minor unless an exception is actually thrown. Sorry about
assuming something unstead of looking it up.

What is that supposed to mean?
> C++ has no notion of managed/unmanaged code.

Even when considering the Microsoft extensions, I still don't see what
> exceptions have to do with managed code. (since you compare exceptions
> to "unmanaged" code that must mean you must consider those "managed")

I wasn't using managed in the technical sense, only to indicate that there's
some additional code laid down on the stack inside a try block that's used
to trace exceptions in a way that doesn't happen otherwise. It's obviously
not managed in the sense that the code starts to perform boundry checking on
arrays or whatnot.

> The divide by zero question is easy to answer, because unless one of the
> > values is volatile, then it's more efficient to check the denominator
> before
> > the division than put the division in a try/catch block.

I don't understand how not using exceptions allow better efficiency.
> If you want to detect the error, you have to make a test in both cases.

I think I was confusing myself. Arithmetic errors aren't handled using
exceptions, so code like
    try {  ... }
    catch (Exception e) {throw DivideByZero}
won't work if the try block contains just the division algorithm. I was
thinking of comparing the above code to
    if (d == 0) throw DivdeByZero;
    else { ... }
Which would be less silly and more efficient, but I have seen the former,
especially in Java. In this case, I think I'm supposed to be comparing the
second example to something that doesn't check for or throw errors at all,
which seems like a bad practice to me, but is how ordinary integer
operations are handled. Right? Am I still crazy?

Regards,
Hugh