But this doesn’t solve the problem.
I believe it solves Daniel’s original issue, i.e. not being able to
use SDL and C++11 (or, more precisely, a C++ dialect with features
from the C++11 standard) together.
But that’s really the problem: suppose Daniel, being sane,
does not want the gnu variant of C++ but prefers standards
conformance?
you have to also consider, many people building stuff on
top of SDL are not making games for their own playing.
They’re making code that other people can build
on other platforms too, using other compilers,
in fact they might be making a library not an application.
You are right in that it does not
solve your issue of “compile once, use everywhere”.
Its “write once, use everywhere”. I.e. my language source
code (Felix) should work on all platforms if you restrict yourself
to platform independent code.
Using SDL to do graphics, for example, should just “work” on
all platforms (that’s the theory and the hope anyhow 
The Felix compiler generates C++, conforming as close as possible
to ISO standards. There is configuration data on each installation,
including, for example, what compiler to use with which switches
to compile the generated C++.
SDL and other libraries may require configuration data for
a given platform. Felix provides a way to specify the include file
path (to find SDL.h) and switches so the linker will link SDL.
However the client (typically) choses the C++ compiler to use once when
installing my system and by default gcc is used on Linux with -std=c++
and clang on OSX with -std=c++11. (because that’s all I can test)
Internal run time libraries can also be built with C, however SDL
isn’t an internal library.
So MY situation is: my clients run on many platforms with many
compilers and there are rules about what they have to provide
in the way of the compiler: it has to have certain capabilities.
For example I recently changed the rules: stdint.h is no longer
optional. int32_t etc must be defined. Felix USED to try to calculate
a suitable alternative (as does SDL) but I gave up on that.
Another rule: the compiler must not do strict aliasing.
So Felix sets --fno-strict-aliasing switch because Felix itself
breaks strict aliasing rules left right and centre
the point is: SDL is a mere library. A very good one, but its just
a library. It must not interfere with the client’s choice of compiler.
SDL is free to build itself any way it wants to ensure
(a) the library binaries are ABI compliant for the platform, and,
(b) the header files are ISO compliant for a suitably chosen standard
It is NOT free to interfere in the compliance requirements by adding
its own versions of functions it thinks are missing. This is the job
of the application or framework or client, it is NOT the job of SDL library.
[Technically its actually the job of the compiler vendor :]
Similarly SDL should NOT make architectural assumptions about the
client always making C code with static linkage including a “main”
function. I don’t. My own system is a framework, IT takes care of the
linkage model and framework requirements its own way.
This is NOT to say SDL should not ALSO provide some useful
frameworks for basic game development, but they should be
clearly separated from the library.
There are libraries around my framework isn’t compatible with
because these libraries think they own the world. One of the
worst culprits is Xlib which insists you run its event loop.
Felix runs its own event loop (you can write Xlib callbacks
or you can use threads, but you lose the fibration and other
features the Felix event loop provides).
Windows on the other hand does it right. The USER has to
write the event loop. In fact no event loop is required.
The thing I like about SDL is that it does NOT mandate an event loop,
it provides SDL_PumpEvents and SDL_PollEvents instead which allows
the client programmer to organise their own infrastructure. This is what makes
SDL such a great product.
So no matter how SDL is built, it has to be used with ANY C++ compiler
without modification and without changing the way it was built.
That is, through no fault of the SDL developers, impossible.
Look at the whole MinGW/g++ vs. MSVC++ story on Windows: the two C++
ABIs are incompatible.
Ok, I should have said “with the same ABI”. Obviously the binaries
should be ABI compliant, and you need a different binary library for each
ABI.
It’s the headers for a given ABI that are at issue here.
SDL’s job is to abstract system-specific details away, and as
Microsoft’s decade-long unwillingness to provide stdint.h shows,
differences between what C/C++ language standard is supported belong
into the category of “system-specific details”.
SDL’s job is to abstract systems specific Graphics, Audio, and
other details away NOT abstract aways problems in standard libraries.
if SDL wants to help with that fine, but such support should be cleanly
separated from the library. The client can then choose to use SDL’s
helper stuff OR do it themselves. Then if things mess up its THEIR
FAULT not SDLs.
For my system this means, if SDL stuff doesn’t work on some
platform and a client complains its MY problem to fix it.
If you give your
clients the power to change such system-specific details on a whim,
well, I guess you’ll have to add code that rebuilds SDL according to
whatever set of flags has been chosen this time around.
How can you do that if you’re using C++ and SDL builds by
“autoconf” magic for some variant of C?
Flexibility
doesn’t come for free.
i agree but the point is this: there’s no good reason for the current
broken design. There’s a right way to do this, and that’s to separate
out the parts of the SDL that can help with adapting broken compilers
from the library.
The need to do this in modern contexts is clear. Already two people have
run into grief, one using C99 and one using gcc with -std=c++11.
As it happens I have NOT had any problems. I’m running OSX 10.6.8 using
gcc 4.2.something and clang 3.3 from SVN (bleeding edge) with LLVM’s
libraries (not gcc’s because they don’t support C++11 which i want to
migrate to eventually). i build plugins and static libraries and SDL
just works with all these combinations (including no SDL_main crud).
What I need is that if I put my code on Linux or Windows with some
compiler being used selected by the client, it will still work, and,
if it doesn’t because some requirement wasn’t met by ME creating
the binding, its MY job to fix it. SDL is denying me the authority
required to do that by taking responsibility for something outside
its scope. (i mean authority and responsibility in the sense
of programming by contract).
The last thing I want to do is have to modify SDL and bundle it
with Felix just to ensure I can remove functions from SDL that
are specified as part of an ISO standard, or specified as NOT
being part (and therefore are not allowed in headers).
I understand your argument and Sam’s but it is fallacious.
It worked well only when compilers, compiler standards, and
linkage models were not so diverse as they are today, when
an SDL app was just SDL and nothing else, whereas today
even a game will have a lot of other stuff in it such as a high
performance physics engine, networking, http interfacing,
and heap of other messy complex stuff. If all those things
also tried to fix broken compilers all hell would break loose.
SDL (the library I mean) shouldn’t try either.On 04/07/2013, at 10:45 AM, Ond?ej Ho?ek wrote:
On Thu, Jul 4, 2013 at 1:21 AM, john skaller <@john_skaller> wrote:
–
john skaller
@john_skaller
http://felix-lang.org
