[SDL] Repeating timers

Mason Wheeler masonwheeler at yahoo.com
Fri Apr 10 08:36:44 PDT 2009

2009/4/1 Bob Pendleton <bob at pendleton.com>:

> 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.


More information about the SDL mailing list