Benchmark of try/catch

[bearophile]

Sergey Gromov:

>Different languages require different idioms, that's my strong opinion.<

I agree a lot, but it seems I need quite more than one year to learn most D idioms. I am just ignorant and willing to learn.


> One really important benchmark would be something like this:
> results
> D: 5.52s
> C++: 4.96s

I have tested the following D and C++ code (note that the C++ code is a single file now):

// D code
class TerminateException {}
void do_stuff(int i) {
    if (i == 1_000_000_000)
        throw new TerminateException;
}
void main() {
    for (int i; ; i++) {
        try {
            do_stuff(i);
        } catch (TerminateException e) {
            break;
        }
    }
}


// C++ code
struct TerminateException {};
void do_stuff(int i) {
    if (i == 1000000000)
        throw TerminateException();
}
int main() {
    for (int i = 0; ; i++) {
        try {
            do_stuff(i);
        } catch (const TerminateException & e) {
            break;
        }
    }
    return 0;
}


My timings are:
N = 1_000_000_000:
  C++: 0.06 s
  D:   5.10 s

Compiled with:
CPU: Core 2 at 2 GHz, 2 GB Ram, Windows XP.

D code compiled with:
  DMD v1.041
  -O -release -inline

C++ code compiled with:
  gcc version 4.3.3-dw2-tdm-1 (GCC)
  -O3 -s

-------------------------------

grauzone:

> Alternatively, one could introduce nullable types:
> int? toInt(char[] s);
> The use of nullable value type int? would be a bit similar to object
> references in D. One can check it for null-ness, and using a null value
> raises a special exception.
> As a third way, one could simply return a tuple:
> (bool, int) toInt(char[] s);

That's nice enough. The return value can be a struct (can contains the result plus a bool (or int) error flag/value).


>>Python3 also removes the find() method of strings, and leaves only the index() method, that is like find(), but raise ValueError when the substring is not found. So you are forced to use exceptions here too.<<

>I'm shocked. That's beyond stupid. Didn't they consider ease of use?<

As usual you must know many details specific of that situation before commenting on a decision (I like the old -1 return value, but Python designers are often able to find design ideas better than my ones).
Here are some discussions on the rationale:
http://mail.python.org/pipermail/python-dev/2005-August/055704.html
http://mail.python.org/pipermail/python-dev/2005-August/055705.html
http://mail.python.org/pipermail/python-dev/2005-August/055708.html
http://mail.python.org/pipermail/python-dev/2005-August/055711.html
http://mail.python.org/pipermail/python-dev/2005-August/055712.html
http://mail.python.org/pipermail/python-dev/2005-August/055717.html
http://mail.python.org/pipermail/python-dev/2005-August/055740.html
http://mail.python.org/pipermail/python-dev/2005-August/055748.html
http://mail.python.org/pipermail/python-dev/2005-August/055754.html
And the discussion doesn't stop there...

Bye and thank you,
bearophile