[SDL] [gsoc] Application proposal suggestion (SDL++)

[Pierre Phaneuf]

On Fri, Apr 3, 2009 at 11:31 AM, Jonathan Dearborn <grimfang4 at gmail.com> wrote:

>> I think one might want to have exceptions as an option, which wouldn't
>> be hard at all if this is a headers-only wrapper.
>
> Aren't exceptions a little slow sometimes?  I'd expect them to be
> #ifdef'ed so I can avoid them.

Exceptions add a number of overheads. One is in terms of code size,
where it has to put in some RTTI info. If you do not disable both RTTI
and exceptions, you're paying that overhead already (it's not absurdly
large anyway). There is a small time overhead when entering scopes
with destructors to call, but it is very small, of the order of a few
instructions, if I remember (and if you're coding in C, you'll
probably have to code the equivalent code by hand anyway, so you're
not necessarily winning). Where it becomes possibly bad is when you
start throwing exceptions and having try/catch blocks. This depends on
the platforms/compilers, but Visual C++, for example, uses the SEH
support in the operating system, which turns out to be pretty slow,
relatively to other techniques. GCC 3.0 and up isn't bad, before that,
meh (but that's getting kind of old now), but there is some overhead
to try/catch blocks. If you don't catch exceptions, they're basically
free, time-wise, and that can actually be a performance advantage,
since you can greatly cut down on the branches (which our fancy
superscalar CPUs don't really like!) and code size of error checking
that just "bubbles up" the errors, you just have error handling where
you actually, well, *handle* the errors.

Exception specifications are to be avoided (see
http://www.boost.org/development/requirements.html#Exception-specification).
They don't even work like most people think: they're not like Java,
where the compiler errors out if you call a method that throws
something you didn't declare, but rather they simply wrap your
function in a try/catch block (which has some overhead) that will call
std::terminate() at runtime if any unexpected exception goes by them
(ouch!).

I think the _EXCEPTIONS pre-processor macro is part of the C++
standard, letting you have alternate behaviour if exceptions are
disabled. You have to be careful about using this in the .cc files of
a library, since it will only reflect your compilation settings, not
those of the application calling you (it's probably okay to disable
exceptions in a library if there is no callbacks to user code, but if
there are, they could throw and your destructors wouldn't get called).

>> One way is to use the typing system to your advantage. For example,
>> making the wrapper for an SDL_Surface *not* a pointer (but rather a
>> pointer-sized object), and not giving it an automatic conversion to
>> SDL_Surface* makes it more difficult to abuse.
>
> This is a good idea.

An idea that isn't always followed... I got screwed over doing pointer
arithmetic once, simply because I had included qstring.h, which has a
bunch of overzealous conversion operators, so instead of "foo + 10"
(where foo is a const char*) returning a const char* 10 characters
into foo, it was returning a pointer inside a new QString (that got
invalidated almost immediately, being a temporary) with the same
content as foo, with the two characters "10" added at the end. Argh.

This can be done right, or can be done wrong. That's why I'm keen on a
widely reviewed "official" implementation. The key is for it to be
both widely reviewed and widely used, which I don't think any of the
current third-party C++ bindings have.

-- 
http://pphaneuf.livejournal.com/