[gsoc] Application proposal suggestion (SDL++)

SDL Development
21

2009/4/1 Bob Pendleton :

In the past I have rather strongly opposed putting this kind of thing in
SDL for the simple reason that C is easier to embed in more other languages
than is C++. And, right now I still oppose putting it in SDL.

As Kornel says, this wouldn’t strictly have to be in the SDL tarball
itself (although I’m saying that it could potentially be so small and
low-impact that it’d be silly to leave out), and most specifically,
embedding SDL in some other language would not involve C++ at all.

We’re talking about a C++ wrapper to SDL, not using C++ in the
implementation of SDL itself.

OTTH, I’m believe this could be a very long process. It is unlikely to be
complete by the time GSOC 2009 ends. The usual first approach to this
problem (as I have seen several times) tends to wind up ignoring a huge part
of what you can actually do with SDL. Not to mention that 1.3 may still
contain instabilities that could result in work stoppages in parts of the
project. So, I expect this to be an iterative process that might not
stabilize during the first few iterations. The person proposing the work
needs to understand that, and the GSOC people need to understand that
successful completion of the project does not imply that the code will be
complete at the end of the sumer.

I’m surprised by this one. I’d expect a C++ wrapper to be both doable
in a very incremental way (start with a tiny subset of the API, and
grow it), and not being extremely difficult to implement (it’s mostly
a matter of translating calls, it’s not like it would do the actual
work). That latter point is all relative of course, but I’ll be damned
if you can’t make a wrapper around an SDL_Surface in a whole bloody
summer! Specifically as I think there are already a number of C++
projects who ended up rolling their own wrappers that covers the parts
of the API that they use, so there should be plenty to draw from and
learn from.

The SDL API itself isn’t that big, although it did increase a good
chunk in 1.3, what makes SDL big is mostly all the various backends.
For example, there are multiple renderers, but they share the same
API, you can wrap that once, and you’ve covered them all.

OTFH, The focus on STL worries me. It may well be that STL approaches are
not applicable. In the 10 seconds (so, yeah, I can be completely wrong) I’ve
spent thinking about this I only see a tiny number of things where STL
concepts are applicable. But, aside from that I believe that starting with
an STL mind set, or any mind set, may keep the project from finding a model
that is well suited for SDL’s application space. We should not accept STL as
the obviously correct starting point.

I think what’s meant by this STL focus is really that the wrapper
should be idiomatic C++ (as Edward pointed out, pretty much the whole
thing that people call the STL is actually just the standard library),
and not some kind of weird dialect specific to this wrapper. The goal
should be that a C++ programmer familiar with the standard library
should feel right at home.–
http://pphaneuf.livejournal.com/

22

If none of the listed projects are currently being ported to SDL 1.3, I definitely think it could be a good idea.

I use SDL with C++ and while it’s not a problem to use it as it is, I think a well designed C++ version of SDL 1.3 which throw exceptions would be extremely useful :slight_smile:

Pat> ----- Original Message -----

From: pphaneuf@gmail.com (Pierre Phaneuf)
To: A list for developers using the SDL library. (includes SDL-announce)
Sent: Thursday, April 2, 2009 5:28:49 PM
Subject: Re: [SDL] [gsoc] Application proposal suggestion (SDL++)

On Thu, Apr 2, 2009 at 7:08 PM, Donny Viszneki <donny.viszneki at gmail.com> wrote:

No, there are not, but there already are SDL C++ bindings, I wasn’t
sure how much more functionality one might need to justify another
SDL/C++ mating, so I suggested this!

Making a razor-thin one that came standard with SDL and wouldn’t add
any build-time requirements for games would be pretty cool, I think.
You’re quite right that there are some, looking around on the library
registry on libsdl.org (and pruning the dead links):

http://sel.sourceforge.net/
http://sdlucid.sourceforge.net/
http://sdlmm.sourceforge.net/
http://burningsmell.org/qdsdl/
http://osdl.berlios.de/

I intentionally left out a bunch of libraries that are “C++ game
libraries” that implement a ton of abstractions and helpers on top.
Some of those are very old, some are somewhat hefty, others are
headers-only, etc… There’s definitely something to learn here, in
any case.

–
http://pphaneuf.livejournal.com/

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

23

First, I hate it when people talk about C++ & STL like they’re two
seperate things. Large tracts of the STL are incorporated into the C++
language definition. It’s just the C++ standard library, okay?

Yeah, I kind of read “STL” as “the standard C++ containers"
nowadays… That’s the C++ equivalent of people calling stdio the
"Portable I/O library”! (I don’t think many people did that in recent
years, though!)

Many C-oriented constructs used within SDL can be tricky to
translate directly into C++ constructs in a way that maintains
compatibility - Exceptions are the best example of this; how do
properly support exceptions, while still maintaining the integrity of
C code? Think of the scenario where someone is porting from C to C++
and wants to leave large chunks of code as C; this happens in the real
world. This is particularly important, as exceptions are about the
only reason to actually write a C++ wrapper for SDL - If you’re not
going to use exceptions, then you may as well use the ‘naked’ C calls,
as you’ll have to do C-style error checking anyway…

I would disagree strongly with the last sentence: not using
exceptions, I would still enjoy a surface class with a destructor that
called SDL_FreeSurface a fair bit!

If you have an existing C++ program that uses exceptions and the
existing SDL API, then it already has to deal with exceptions being
thrown. My personal opinion is that I don’t really like code that’s
exception-happy, but that they make sense in two main cases,
constructors (rather than returning an half-constructed object and
having to check some is_valid() method), and places where some strong
pre-conditions are being violated (somewhere you might think of
putting an assert, for example). Trying to lock a STATIC texture, for
example, is most likely a programming error, and if you have a generic
function where you have a fallback strategy, then you can catch it in
that situation (if you don’t know what to do, just let it go through).

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.

Wrapping structs in classes exposes some weaknesses in the SDL APIs.
For example, SDL_UnionRect doesn’t translate well into
sdl::Rectangle::union(), for obvious reasons, but actually, more
importantly, it isn’t a union operation; SDL_UnionRect returns an
SDL_Rect that is large enough to enclose both the rectangles passed
in. So, you have 2 weaknesses; a name that is a reserved word in
another language and an API that doesn’t describe acurately what it
does.

Choosing a different name isn’t all that difficult (you could have
picked “get_union” as a method name, for example), and I think that we
should take advantage of the fact that the new 1.3 API are not stable
yet to fix these kinds of issues (this SDL_UnionRect really calculates
a bounding box, it should be renamed accordingly). We can’t touch
anything that was in 1.2 (not without providing a compatibility fix in
SDL_compat.h, anyway), but there’s no excuse for altogether new
functions being marked “stable” with such a misleading name!

There might be some tricky decisions with some existing stuff, whether
it would get “fixed” in the C++ wrapper, or whether it should remain
close to the API it is wrapping. I’m not entirely sure what the proper
choice is here.

Automatic memory management should be used with extreme care. This
is particularly difficult when dealing with C comptibility; what
happens when someone makes a C call to free memory? This makes things
VERY tricky. I would argue that it is not merely sufficient to say
"well if they do that, it’s their own fault" - “A library should be
easy to use and difficult to misuse” - one has to find a way to
enforce behaviour to prevent mixed code from failing. How do you do
that without cripplling the performance?

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. You couldn’t do this,
for example:

void myfunction(SDL::Surface foo) {
SDL_FreeSurface(foo);
}

That doesn’t stop someone from trying hard and doing
SDL_FreeSurface(&foo), but I don’t think you can save everyone. They
actually had to type that ampersand, the conversion didn’t happen
automatically in some unexpected way, and they could very easily do
the same with any C++ object in an equally wrong way.

I’m more worried about finding a clear way to explain the semantics of
that hypothetical SDL::Surface class, where copying it wouldn’t
actually make a new surface with a copy of the content… Maybe the
way is simply to call the class SDL::SurfaceRef, but there’s more
cases where the underlying SDL semantics would be hard to contain well
(C++ libraries aren’t usually big on global state, for example, so the
whole initialization business would be rather icky).

The conclusion I drew from this, is that, actually, the “best” way
to design a C library, is to design it alongside the bindings for
atleast 2 other languages (rule-of-three). In the case of SDL, the
obvious choices are C++ (real-world) and Python (PyGame being as well
know as it is). It’s not so much about making it work perfectly with
every other language, it’s about thinking about the problem in
different ways to allow you to spot problems you may have otherwise
missed.

I agree entirely, but (thankfully!) the idea is not to design a C
library, or to revisit SDL’s API design here.On Wed, Apr 1, 2009 at 8:54 PM, Edward Cullen wrote:

–
http://pphaneuf.livejournal.com/

24

If none of the listed projects are currently being ported to SDL 1.3, I definitely think it could be a good idea.

SDLmm seems to have had some recent activity, if that’s the case, they
might be working on 1.3 right now, for all we know…On Thu, Apr 2, 2009 at 8:01 PM, Patryk Bratkowski wrote:

–
http://pphaneuf.livejournal.com/

25

I would disagree strongly with the last sentence: not using
exceptions, I would still enjoy a surface class with a destructor that
called SDL_FreeSurface a fair bit!

I agree!

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.

Choosing a different name isn’t all that difficult (you could have
picked “get_union” as a method name, for example), and I think that we
should take advantage of the fact that the new 1.3 API are not stable
yet to fix these kinds of issues (this SDL_UnionRect really calculates
a bounding box, it should be renamed accordingly). We can’t touch
anything that was in 1.2 (not without providing a compatibility fix in
SDL_compat.h, anyway), but there’s no excuse for altogether new
functions being marked “stable” with such a misleading name!

I nominate: SDL_UnionRect -> SDL_BoundingRect

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.

I hope to see an interface that is actually fun to use (though, no, I
haven’t checked out the existing wrappers)… Default arguments,
overloading, etc. make me happy. SDL_CreateRGBSurface(tons of args
that I have to remember) does not.

Jonny DOn Thu, Apr 2, 2009 at 8:24 PM, Pierre Phaneuf wrote:

26

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.On Fri, Apr 3, 2009 at 11:31 AM, Jonathan Dearborn wrote:

–
http://pphaneuf.livejournal.com/

27

Here’s a start (see attachment). Let the flame war begin!

One obvious extension, which I’ve left out for the moment, is pixel access via
surface(x, y) = c; and c = surface(x, y);. It’s a lot easier to implement
with an intermediate pixel class (that is, surface(x,y) returns a pixel
instance which actually sets or gets the pixel value through assignment /
conversion routines).

-------------- next part --------------
A non-text attachment was scrubbed…
Name: sdlpp.cpp
Type: text/x-c++src
Size: 6698 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20090403/002c5efc/attachment.cppOn Thursday 02 Apr 2009 20:01:14 Patryk Bratkowski wrote:

If none of the listed projects are currently being ported to SDL 1.3, I
definitely think it could be a good idea.

I use SDL with C++ and while it’s not a problem to use it as it is, I think
a well designed C++ version of SDL 1.3 which throw exceptions would be
extremely useful :slight_smile:

Pat

28

Can this be done efficiently? Check out the thread
ReadPixels/WritePixels or something similar.On Fri, Apr 3, 2009 at 6:39 PM, Kenneth Bull wrote:

One obvious extension, which I’ve left out for the moment, is pixel access via
surface(x, y) = c; and c = surface(x, y);. ?It’s a lot easier to implement
with an intermediate pixel class (that is, surface(x,y) returns a pixel
instance which actually sets or gets the pixel value through assignment /
conversion routines).

–
http://codebad.com/

29

If you store a pointer in the pixel object instead of calculating the memory
location each time, then yes. you could then have operations on the pixel
object itself like inc_x and inc_y to avoid the multiplication needed for
surface(x,y). (ptr += pitch; instead of ptr = pixels + ypitch + xbpp)On Friday 03 Apr 2009 20:20:12 Donny Viszneki wrote:

On Fri, Apr 3, 2009 at 6:39 PM, Kenneth Bull <@Kenneth_Bull> wrote:

One obvious extension, which I’ve left out for the moment, is pixel
access via surface(x, y) = c; and c = surface(x, y);. It’s a lot easier
to implement with an intermediate pixel class (that is, surface(x,y)
returns a pixel instance which actually sets or gets the pixel value
through assignment / conversion routines).

Can this be done efficiently? Check out the thread
ReadPixels/WritePixels or something similar.

30

Hello!

I’m new here. Just thought I’d jump in on this with some comments/questions
about your proposed wrapper.

  1. Are you against using something like Boost? I believe Boost has a very
    well tested smart pointer that could effectively replace your homegrown
    wrapper class. While I’m not suggesting your code is bad, I think not
    reduplicating effort would be good. As far as I know, the Boost::shared_ptr
    class is a header-only class, so you could (license allowing) merely ship
    this with the wrapper. I also believe this class is being added to C++0x,
    so you could effectively phase the Boost header out over time.

  2. After a really brief, shallow look, I am not very comfortable with your
    surface class inheriting from a templated wrapper class. Do you need to
    inherit from it? Unless you’re doing something far more complex than I saw,
    I think you could get away without any inheritance. In relation to the
    previous question, you could instantiate and free (with a custom delete) a
    boost::shared_ptr fairly effectively:

    class surface {
    public:
    surface() : surface_ (SDL_CreateSurface …, SDL_FreeSurface)
    { }

     private:
     boost::shared_ptr<SDL_Surface> surface_;

    };

Sorry if that code got botched.

  1. How do you plan to implement ownership semantics with a free() method in
    the surface class? If you explicitly free the SDL_Surface that is used by
    many of your surface classes, won’t something bad happen eventually?

  2. I think Herb Sutter talks about how exception specifications are
    generally NOT a good thing to include in your code (like you did in the
    wrapper class). Though this article is from 2002, I think at least some of
    it is still relevent: http://www.gotw.ca/publications/mill22.htm

Sorry if these questions seem trivial or I missed prior discussion on this.
I looked around before this, but I more than likely am not the first to ask
these questions.

Thanks for your time,

Cody MillerOn Fri, Apr 3, 2009 at 3:39 PM, Kenneth Bull wrote:

On Thursday 02 Apr 2009 20:01:14 Patryk Bratkowski wrote:

If none of the listed projects are currently being ported to SDL 1.3, I
definitely think it could be a good idea.

I use SDL with C++ and while it’s not a problem to use it as it is, I
think
a well designed C++ version of SDL 1.3 which throw exceptions would be
extremely useful :slight_smile:

Pat

Here’s a start (see attachment). Let the flame war begin!

One obvious extension, which I’ve left out for the moment, is pixel access
via
surface(x, y) = c; and c = surface(x, y);. It’s a lot easier to implement
with an intermediate pixel class (that is, surface(x,y) returns a pixel
instance which actually sets or gets the pixel value through assignment /
conversion routines).

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

31

Hi Cody, welcome to the list!

I don’t think using boost is a good idea for this unfortunately.
Although many boost libraries (including the smart pointer libs, and
other potentially useful-but-easy things like boost::noncopyable) are
header only, splitting them out from the rest of boost to be included in
SDL would, I believe, be a pain.

I’ve done this before (pulling out the boost smart ptr headers to be
used in a project that needed to be portable to platforms without boost
installed), and you actually end up with a lot of boost code being
pulled in, because of the big boost config and platform compatability
header system. I’m sure you could cut out lots of things from the
headers to reduce this problem, but then you’re refactoring boost, and I
don’t see why spending your time doing that is better than spending the
same time writing a few custom smart-pointer style wrappers.

Once that’s been done, you end up with a little bit of boost (or
possibly just a bit of nearly-boost) in SDL++. Now what happens when
someone actually does have a real boost install (which would be pretty
common) – now you’ve got your own headers mixing with the real boost
headers, and everything gets a little dangerous. Again, this isn’t an
insurmountable problem – I expect there’s some hackery that could be
done to avoid problems and favour the real boost install if there is
one, but it does get a bit hairy.

But finally, and most importantly, I actually don’t think using boost
smart pointers adds much in this case. Smart pointers are frankly not
that hard to write, and with a little googling to check for the common
mistakes they’re not that hard to write correctly, but in the case of
things like wrappers for SDL_Surface, you don’t want a generic smart
pointer anyway, because you don’t want to use normal new/delete or
malloc/free – SDL already has specific allocation and deallocation
methods for SDL_Surface, and those are what you should be using in its
C++ wrapper. boost::shared_ptr<SDL_Surface> is a red herring too,
because SDL_Surface already includes its own reference count field
(which SDL_FreeSurface respects) – an SDL_Surface wrapper should simply
use that (in boost terms it would have to be boost::intrusive_ptr<>).

Disclaimer: I’m not a regular on the list myself, so my opinion may
carry less weight than others.

Regards,

John B

Cody Miller wrote:>

Hello!

I’m new here. Just thought I’d jump in on this with some
comments/questions about your proposed wrapper.

  1. Are you against using something like Boost? I believe Boost has a
    very well tested smart pointer that could effectively replace your
    homegrown wrapper class. While I’m not suggesting your code is bad, I
    think not reduplicating effort would be good. As far as I know, the
    Boost::shared_ptr class is a header-only class, so you could (license
    allowing) merely ship this with the wrapper. I also believe this
    class is being added to C++0x, so you could effectively phase the
    Boost header out over time.
32

I’m basing my comment not on anything I know about SDL or C++ but on a
series of projects I was involved in as a teaching assistant when I
was in grad school oh these many long years ago. At the time it was
noticed that certain languages, in particular Fortran and C (this was
between '81 and '83) were becoming ubiquitous. Every architecture and
OS supported one or both of those language. So, it seemed like a good
idea to compile languages such as LISP and Pascal to C and Fortran. At
first, second, and even third glance it seems like compiling Pascal to
C is trivial, just a simple transliteration, not a full compilation.
And then you notice nested functions in Pascal and every thing
stops…

Until a design is proposed and at least partially implemented we will
not know what detail is going to kill it.

Bob PendletonOn Thu, Apr 2, 2009 at 6:42 PM, Pierre Phaneuf wrote:

2009/4/1 Bob Pendleton <@Bob_Pendleton>:

In the past I have rather strongly opposed putting this kind of thing in
SDL for the simple reason that C is easier to embed in more other languages
than is C++. And, right now I still oppose putting it in SDL.

As Kornel says, this wouldn’t strictly have to be in the SDL tarball
itself (although I’m saying that it could potentially be so small and
low-impact that it’d be silly to leave out), and most specifically,
embedding SDL in some other language would not involve C++ at all.

We’re talking about a C++ wrapper to SDL, not using C++ in the
implementation of SDL itself.

OTTH, I’m believe this could be a very long process. It is unlikely to be
complete by the time GSOC 2009 ends. The usual first approach to this
problem (as I have seen several times) tends to wind up ignoring a huge part
of what you can actually do with SDL. Not to mention that 1.3 may still
contain instabilities that could result in work stoppages in parts of the
project. So, I expect this to be an iterative process that might not
stabilize during the first few iterations. The person proposing the work
needs to understand that, and the GSOC people need to understand that
successful completion of the project does not imply that the code will be
complete at the end of the sumer.

I’m surprised by this one. I’d expect a C++ wrapper to be both doable
in a very incremental way (start with a tiny subset of the API, and
grow it), and not being extremely difficult to implement (it’s mostly
a matter of translating calls, it’s not like it would do the actual
work). That latter point is all relative of course, but I’ll be damned
if you can’t make a wrapper around an SDL_Surface in a whole bloody
summer! Specifically as I think there are already a number of C++
projects who ended up rolling their own wrappers that covers the parts
of the API that they use, so there should be plenty to draw from and
learn from.

–
±----------------------------------------------------------

33

boost::shared_ptr<SDL_Surface> is a red herring too,
because SDL_Surface already includes its own reference count field
(which SDL_FreeSurface respects) – an SDL_Surface wrapper should simply
use that (in boost terms it would have to be boost::intrusive_ptr<>).

I keep forgetting about that…

Cody Miller wrote:

  1. Are you against using something like Boost? I believe Boost has a
    very well tested smart pointer that could effectively replace your
    homegrown wrapper class. While I’m not suggesting your code is bad, I
    think not reduplicating effort would be good. As far as I know, the
    Boost::shared_ptr class is a header-only class, so you could (license
    allowing) merely ship this with the wrapper. I also believe this
    class is being added to C++0x, so you could effectively phase the
    Boost header out over time.

I’m not really a fan of boost myself and I certainly wouldn’t want it as a
dependency… and I definitely wouldn’t look forward to wading through their
source code to grab the parts required.On Saturday 04 Apr 2009 07:27:44 John Bartholomew wrote:

34

Pierre Phaneuf wrote:> On Thu, Apr 2, 2009 at 7:08 PM, Donny Viszneki <donny.viszneki at gmail.com> wrote:

No, there are not, but there already are SDL C++ bindings, I wasn’t
sure how much more functionality one might need to justify another
SDL/C++ mating, so I suggested this!

Making a razor-thin one that came standard with SDL and wouldn’t add
any build-time requirements for games would be pretty cool, I think.
You’re quite right that there are some, looking around on the library
registry on libsdl.org (and pruning the dead links):

http://sel.sourceforge.net/
http://sdlucid.sourceforge.net/
http://sdlmm.sourceforge.net/
http://burningsmell.org/qdsdl/
http://osdl.berlios.de/

I would add http://libwt.sourceforge.net/ also to the list.

Although libwt tries to be the Qt equivalent, build on top of SDL with signal / slots,
widgets, layout and its own event loop, libwt does provide an independent SDL layer (in wt/sdl*.{h,cpp})
which basically wraps the SDL in C++ and has none of the above GUI features.

Furthermore:

  1. It doesn’t do exceptions
  2. It uses boost for surface management
  3. it also wraps the sdlmixer

</shameless plug>

 .bill
35

2009/4/3 Pierre Phaneuf :

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.> On Fri, Apr 3, 2009 at 11:31 AM, Jonathan Dearborn wrote:

36

Not SDL, but should be interesting for someone:

http://www.sfml-dev.org/On Sun, Apr 5, 2009 at 5:58 AM, Edward Cullen wrote:

2009/4/3 Pierre Phaneuf :

On Fri, Apr 3, 2009 at 11:31 AM, Jonathan Dearborn 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

37

Has this project been accepted?

Bob PendletonOn Fri, Apr 3, 2009 at 5:39 PM, Kenneth Bull wrote:

On Thursday 02 Apr 2009 20:01:14 Patryk Bratkowski wrote:

If none of the listed projects are currently being ported to SDL 1.3, I
definitely think it could be a good idea.

I use SDL with C++ and while it’s not a problem to use it as it is, I think
a well designed C++ version of SDL 1.3 which throw exceptions would be
extremely useful :slight_smile:

Pat

Here’s a start (see attachment). ?Let the flame war begin!

One obvious extension, which I’ve left out for the moment, is pixel access via
surface(x, y) = c; and c = surface(x, y);. ?It’s a lot easier to implement
with an intermediate pixel class (that is, surface(x,y) returns a pixel
instance which actually sets or gets the pixel value through assignment /
conversion routines).

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
±----------------------------------------------------------

38

One obvious extension, which I’ve left out for the moment, is pixel access via
surface(x, y) = c; and c = surface(x, y);. ?It’s a lot easier to implement
with an intermediate pixel class (that is, surface(x,y) returns a pixel
instance which actually sets or gets the pixel value through assignment /
conversion routines).

Can this be done efficiently? Check out the thread
ReadPixels/WritePixels or something similar.

Donny, that is the wrong question. In some cases it will be efficient,
in some it will not. The point is that someone will need to do it.
If you need it, then what ever it costs is efficient.

I’m temped to point out the the word “efficient” doesn’t have a
meaning in this context because we do not know what the actual cost
(which is very different from the number of cycles spent) is so we
can not compute the cost benefit ratio. No cost benefit ratio? Then
"efficient" has no meaning.

In my humble opinion most of the long running discussions on ever list
I have ever been on are the result of people believing that a word
always has a meaning. It simply isn’t true. Some times words have no
definition in the current context.

Bob PendletonOn Fri, Apr 3, 2009 at 7:20 PM, Donny Viszneki <donny.viszneki at gmail.com> wrote:

On Fri, Apr 3, 2009 at 6:39 PM, Kenneth Bull wrote:

–
http://codebad.com/

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
±----------------------------------------------------------

39

There is no need to worry about this. Just install Boost. SDL does
not contain the text of every library that it uses. No need to.

Please remember that at the current time this project would be an “off
to the side” package that could be used with SDL, not part of the
core.

Don’t borrow problems.

Bob PendletonOn Sat, Apr 4, 2009 at 6:27 AM, John Bartholomew wrote:

Hi Cody, welcome to the list!

I don’t think using boost is a good idea for this unfortunately. Although
many boost libraries (including the smart pointer libs, and other
potentially useful-but-easy things like boost::noncopyable) are header only,
splitting them out from the rest of boost to be included in SDL would, I
believe, be a pain.

–
±----------------------------------------------------------

40

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.

OTOH, if you know that the return type is a rect, you know it can’t
literally be the union, it must be a bounding box.–
http://codebad.com/