Re : Opaque Objects / Pointers

I discovered SDL about 8 years ago or more, at the age of version 0.8 or something.
I was not so good at programming, discovering the Linux & free software world.

I’ve never been confused or lost in the SDL documentation (which has been kept, in the form, more or less as it is now, with all the new features since then).
The data structures, included more complex ones like SDL_Event, has always seemed very clear to me, also thanks to the good examples provided with the lib.

I think that something like “SDL_Surface_width” or any other kind of accessor would only be useful if it is planned to modify the internal SDL_Surface structure and ensure that previous source codes still remain compatible with further releases of SDL. Any other reason like preventing a developer from writing “surface->w = 100;” is not a good argument at all, IMHO. I’d not be too mean but somebody writing such a statement is either very tired, or better for him doing something else than writing programs.

As for the clone function, I also think it is missing. It’d be very useful.
Personally I use display surfaces, so copying surf1 into surf2 is just matter of doing:

surf2 = SDL_DisplayFormat(surf1);

(provided that surf1 is also in the display format)

Concerning C++ and operator overloading, I share David’s point of view. I feel they are useful in specific situations, and generally speaking, they should be avoided.
You have no way to know just by reading a statement like “surf1 = surf2” if you’re making a deep or a light copy. If you overload, can you do a simple pointer assignation anymore ?

To finish, pointers are known to be dangerous, that’s true. They require strong skills and experience to be mastered. You said there’re backends to languages with no pointers. Of course, if you take Java as an example, every object is a reference, which is far less dangerous than pointers.
If someone want to avoid pointers, better switching to another language. I don’t see the problem with SDL, it is just nicely coded and the C interface is glass clear… and really really portable ! Thank you Sam :slight_smile:

Don’t bring C++ like APIs in SDL, please, please… ^^


----- Message d’origine ----De : Eddy Cullen
? : A list for developers using the SDL library. (includes SDL-announce)
Envoy? le : Samedi, 19 Juillet 2008, 22h44mn 05s
Objet : Re: [SDL] Opaque Objects / Pointers

David Olofson wrote:

On Saturday 19 July 2008, Eddy Cullen wrote:

Shifting responsibilities in that direction tends to also mean
shifting them away from the compiler to run-time type checking -
that is, slower code… Next, we run into a whole new set of
issues with typos, accidentally sending the wrong object to the
wrong place etc; stuff that an experienced C programmer expects
the compiler to trap right away.

Interestingly, by ‘shifting responsibilities’, I meant from the user
to the library developer, not compiler to run-time.

That may or may not be the same thing; they’re more or less

I really don’t know what you mean here - if they’re more-or-less
orthogonal, how can they be the same thing?

That said, what are these benefits you’re seeing?

When dealing with ‘complex’ structures, that is a structure
requiring a deep copy (one for which a = b is semantically

Nothing requires a deep copy. It’s an expensive operation that you
only want done when you really need it - and that is, in most SDL
applications, never. :slight_smile:

Besides, “a = b” is not semantically incorrect in any way; it just
means “copy the pointer value held in ‘b’ into ‘a’”. :wink:

LOL, okay Mr Smarty-Pants, just for you, I’ll be explicit.

When I said ‘a structure requiring a deep copy…’, I meant:

‘where obtaining a separate, independent copy of a structure and its
data requires a deep copy to be performed (where a = b is not
sufficient; where a = b is semantically incorrect).’

But I thought that was pretty obvious… :wink:

Seriously though…

Personally, I dislike APIs that try to wrap things like this. C++ APIs
that “abuse” operator overloading to do this are even worse. It can
be “handy” and (in the case of C++) make the code look cleaner, but
for the most part, it just means you have to double check everything
all the time to be sure what’s actually going on.

Is that really the case? The reason I chose SDL_Surface as an example,
is that it’s not immediately obvious how to clone it just by looking at
a list of functions (okay, could be ‘fixed’ by documentation, but surely
that is the definition of ‘less intuitive’). Also, the documentation states:

 /* This structure also contains private fields not shown here */

So it is at least semi-opaque already. Why not define the API to include
functions for querying the (almost exclusively) read-only data?

Granted, it may not be quite as nice to write:

SDL_Surface_width(surface);                          (1)

as it is:

surface->w;                                          (2)

But it would prevent a user from doing:

surface->w = 100; /* Semantically incorrect */

And it does, at least to me, seem 100% more obvious what surface refers
to in (1) when compared to (2). Again, the majority of overhead of
development is in maintenance, so the pain of typing a really verbose
statement, like (1) is surely off-set by the saving you’ll get when the
code is re-visited?

I have been led to believe that information hiding is a Good Thing.

It is, generally, but I don’t see how trying to hide fundamental
language constructs like pointers can ever be a Good Thing. The
correct solution to that problem is using a higher level language
that avoids these constructs entirely.

Well, given that pointer abuse remains one of the most common causes of
errors (OMFG, you should see some of the code I have to maintain at
work!), and that almost every language since C has tried to do exactly
that (even C++), I can’t see how ‘hiding pointers’ can be called a Bad
Thing. That is to say, if you don’t need to expose a pointer, what’s
the point (pun intended) of putting power and temptation into the hands
of a user?

Or lets look at it another way… SDL isn’t used ‘just’ in C programs -
it has bindings for many other languages, some of which don’t even HAVE
the concept of a pointer.

Now, I’m not saying deep copy of an SDL_Surface would be useless
(though I can’t remember ever needing it), but that’s just a matter
of adding a call SDL_CloneSurface() or something. IMNSHO, it’s a rare
special case, that does not, in any way, motivate any overall API
design changes.

But what if you DO need to do it? Granted, one can clone a surface using:

 new_surface = SDL_CreateRGBSurface(old_surface->flags,
     old_surface->w, old_surface->h,
 SDL_BlitSurface(new_surface, NULL, old_surface, NULL);

But that seems a little obtuse to me.

 new_surface = SDL_CloneRGBSurface(old_surface);

Would do the same job, except neater. It would also prevent people
trying to copy the structure manually, as shown in the documentation.

The issue, in my view, is that C lacks explicit support for it. Can
this be worked-around in a way that users find easy to understand,
use, etc?

Well, you can make all structs “private” and provide function calls to
access the information instead, but all you gain from that is some
minor extra freedom in changing SDL internals without breaking source
and/or binary compatibility with applications, at the cost of
potentially significant overhead.

Yes, that’s the problem isn’t it… this is basically the problem
Stroustrup had when he first started to develop C++; people started to
circumvent the protection mechanism in order to avoid the overhead of a
function call, just to get at a member value, such as an int.

Surely, the goal of a library provider, is to do exactly that; provide
an interface that is stable, that a user can work to with certainty,
while allowing the library developer as much freedom as possible to
change the implementation details?

Incidentally, I’m not talking about all structs, for example, SDL_Rect
is simple (and small) enough to be perfectly understandable and safe
as it is, making it opaque would just be silly. SDL_Surface, on the
other hand, has up to 3 levels of indirection
(Surface->PixFormat->Palette->Color) and that’s just in the public part!

What are peoples experiences with it?

My experience is that overdoing this just leads to overcomplicated,
inefficient APIs for no real gain whatsoever.

IMHO, the SDL API is a brilliant example of how to do it right. It’s
lean and mean, easy to learn, efficient, and still allows backends
enough slack to do some pretty odd things. (Think glSDL…)

I’m not saying it doesn’t. I am asking if it is perfect and if it
isn’t, how can I help to improve it?


SDL mailing list
SDL at


Envoyez avec Yahoo! Mail. Une boite mail plus intelligente

Oh yes, guys, my email was so long, and you said exactly what was in my mind so cleary, and using a better english, thank you ^^

----- Message d’origine ----De : jeroen clarysse <jeroen.clarysse at>
? : A list for developers using the SDL library. (includes SDL-announce)
Envoy? le : Samedi, 19 Juillet 2008, 23h24mn 36s
Objet : Re: [SDL] Opaque Objects / Pointers

I consider this statement the end of it all : one can implement an
opaque concept on top of SDL as it is now, but not vice versa.

that’s why SDL is so good.

If you really need the black box so desperately, make wrapper and
force your team to use that one.

Hello !

Theoretical it is better to hide information
from the user, like how for example the width
of a surface is implemented as an int or as a float.

But things like width of a surface and other small
infos tend to be asked a lot, so it really decreases the
performance of your app.

If you want to make SDL better, write a SDL helper lib
and add all the functions like SDL_CloneSurface, SDL_GetPixel,
SDL_SetPixel and every other function that is not needed in SDL
directly, but maybe nice to have to it.


SDL mailing list
SDL at

SDL mailing list
SDL at


Envoyez avec Yahoo! Mail. Une boite mail plus intelligente

Concerning C++ and operator overloading, I share David’s point of view. I feel they are useful in specific situations, and generally speaking, they should be avoided.>You have no way to know just by reading a statement like “surf1 = surf2” if you’re making a deep or a light
copy. If you overload, can you do a simple pointer assignation anymore ?

I don’t think he meant overloading operations between pointers… That would be weird. I think he means the normal stuff:
Object a, b;
a = b;
Object* a = new Object, b = new Object;
*a = *b;
… to be overloaded to produce deep-copies.

Jonny D

A possible reason why C has been so popular is that it proved his capacity
to bring about very serious software like Unix …

My personal opinion is that C is not really a language, but rather a superset over
assembly, or, if you prefer, a cross-platform assembly. Nothing is hidden to the
developer who can write his own memory manager, and whatever his wants to, with the limitations of the host operating system, allowing deep optimizations. This is one aspect of software development. When you know that in C, “char” doesn’t really mean “a character” but “a chunk of memory with size 1/2 bytes”, you begin to see how stupid C is, and how much it counts on your knowledges. The more stupid the language, the more free the developer, in some way.

I don’t really see the point of that thread. We’re going so far from what this mailing
list is aimed at, isn’t it ?
SDL is coded in C, it has backends for many languages, it works on an incredible number
of operating systems. Think twice before wanting to bring about a revolution in the API
of a library which has been used in commercial games, and proved his high
quality. The world is so nice isn’t it … :wink:

You can consider the Allegro library which is far more complete than SDL in the same area.
I used it in the past. But I prefer SDL for his simplicity. It has the necessary functionalities to fulfill its goal, and a lot of add-on libraries exist to fulfill more particular goals like SDL_net, SDL_image, SDL_TTF … Allegro is SDL+SDL image+SDL net+SDL ttf, if I may, don’t be picky on this remark.


----- Message d’origine ----De : Jonathan Dearborn
? : A list for developers using the SDL library. (includes SDL-announce)
Envoy? le : Dimanche, 20 Juillet 2008, 2h35mn 19s
Objet : Re: [SDL] Opaque Objects / Pointers

This is such an obvious improvement, and Borland’s been doing it for over a decade. Anyone know why C/C++ has never caught on?

It’s used in some areas, but C and variants have dominated the
market, there are other languages that gain footholds here and there,
but C and C++ aren’t going away any too soon.

“So, Lone Starr, now you see that evil will always triumph because good is dumb.”
-Dark Helmet


Envoyez avec Yahoo! Mail. Une boite mail plus intelligente

My question to you is, then, in what do you think the current API
is not user-friendly ? It’d be easier for us to discuss seriously if
you simply list the critical points of it.


----- Message d’origine ----De : Eddy Cullen
? : A list for developers using the SDL library. (includes SDL-announce)
Envoy? le : Dimanche, 20 Juillet 2008, 4h18mn 55s
Objet : Re: [SDL] Opaque Objects / Pointers

You’re missing the point of my question entirely. It’s not a question of
the capabilities of SDL, it is about how the are expressed to the user.
Can the APIs be presented in a different way that is more user-friendly?

If SDL were fully implemented in C++ it probably wouldn’t be that much
bigger, because the developers stick to a sub-set of C++ that had the
lowest overhead and would take advantage of things like inlining and
templates that would actually reduce the size of the run-time code (yeah
the lib might be bigger).

C++ only really grows over C when you start to use things like
exceptions; the run-time and size overhead of using inheritance isn’t
actually that big (1 or 2 extra level of pointer indirection), unless
you go crazy, that is…

Jonathan Dearborn wrote:

Isn’t SDL_ConvertSurface pretty much what you’re asking for in the way
of deep-copy? I agree with David that we can’t have SDL as a low-level
library that forces programmers to work on a higher level. There is
enough functionality that is missing from SDL for people to implement
because SDL just lets you get access to stuff more easily. SDL cannot
be everything to everyone, while still fulfilling its mission, so it has
to open up its structs a little. If SDL were fully implemented in C++,
the function and method overhead would be a little crazy, which makes
all the gray-bearded and pint-size CPUs sad.

Jonny D

SDL mailing list
SDL at

SDL mailing list
SDL at


Envoyez avec Yahoo! Mail. Une boite mail plus intelligente