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

fungos fungos at gmail.com
Sun Apr 5 07:04:07 PDT 2009

Not SDL, but should be interesting for someone:


On Sun, Apr 5, 2009 at 5:58 AM, Edward Cullen
<screamingwithnosound at googlemail.com> wrote:
> 2009/4/3 Pierre Phaneuf <pphaneuf at gmail.com>:
>> 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).
> I had several reasons for my point about 'SDL++' being written with
> exceptions / 'if you don't use exceptions, you may as well use the
> naked C':
> 1. In practice, if a developer is more concerned about not paying the
> exception overhead, then they will be integrating C SDL call directly
> into their own class heirarchy; writing RAII wrappers is trivial.
> 2. Multiple methods of error handling are an ABSOLUTE no-no; providing
> EITHER C-style OR exceptions reduces the complexity of your code and
> improves certainty for the user. I just don't think that adding C++
> wrappers without using exceptions adds enough value to justify the
> effort. If we were talking about a 'pure' C++ library, then, yes, I
> can see the *need* for exception and non-exception code (but I'd still
> say dual error-handling is wrong), but we're not, we're talking about
> a C++ wrapper for a C library...
>>>> 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.
> As I said before, adding official support for other languages has a
> potential benefit for feeding back into the design of C++.
> Pierre Phaneuf wrote:
>> I nominate: SDL_UnionRect -> SDL_BoundingRect
> I've actually got a whole treatise on naming of things and what have
> you, but I think that 'Enclose' is an equally-good or better
> candidate.
> Kenneth Bull wrote:
>> I'm not really a fan of boost myself and I certainly wouldn't want it as a
> dependency...
> I agree, having Boost as a dependency would be less than ideal. As to
> not being a fan of Boost... that is unfortunate, as it is the
> semi-official (the main developers head-up the C++ standards
> committee) future library / prototyping area for C++ standard library.
> In fact, many elements of Boost have *already* been integrated into
> TR1.
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Animal Frontline Liberation

More information about the SDL mailing list