C++ is a bit of a minefield on Android. Much functionality still doesn't work, and Android can't decide on which C++ standard library to use, so it provides 3 different ones, all of which are incompatible with each other. (It looks like clang is coming too which will add a new compiler and a 4th standard library.)
As middleware, SDL might be distributed as a binary and intermixed with other projects already using C++. If C++ is intermixed in a bad way, bad things will happen. Removing dependencies on C++ will avoid this problem and downstream users won't have to worry/care.
This will help reduce issues like that reported in bug 1819:
Wouter van Oortmerssen 2013-04-23 20:12:07 EDT
#0 0x01d1e881 in __HALT ()
#1 0x01c58971 in _CFRuntimeCreateInstance ()
#2 0x02e4acc1 in GSFontCreateWithName ()
#3 0x00adc0e1 in UINewFont ()
#4 0x00adc24c in +[UIFont systemFontOfSize:traits:] ()
#5 0x00adc298 in +[UIFont systemFontOfSize:] ()
#6 0x009fb5d9 in +[UITextFieldLabel defaultFont] ()
#7 0x00a8ccd5 in -[UILabel _commonInit] ()
#8 0x00a8ce14 in -[UILabel initWithFrame:] ()
#9 0x00a052eb in -[UITextField createTextLabelWithTextColor:] ()
#10 0x009fbede in -[UITextField initWithFrame:] ()
#11 0x00152ead in -[SDL_uikitview initializeKeyboard] at /Users/aardappel/lobster/external/SDL-2.0.0-7046/Xcode-iOS/SDL/../../src/video/uikit/SDL_uikitview.m:208
#12 0x0015290c in -[SDL_uikitview initWithFrame:] at /Users/aardappel/lobster/external/SDL-2.0.0-7046/Xcode-iOS/SDL/../../src/video/uikit/SDL_uikitview.m:50
#13 0x00153b5b in -[SDL_uikitopenglview initWithFrame:scale:retainBacking:rBits:gBits:bBits:aBits:depthBits:stencilBits:majorVersion:] at /Users/aardappel/lobster/external/SDL-2.0.0-7046/Xcode-iOS/SDL/../../src/video/uikit/SDL_uikitopenglview.m:53
#14 0x001524ff in UIKit_GL_CreateContext at /Users/aardappel/lobster/external/SDL-2.0.0-7046/Xcode-iOS/SDL/../../src/video/uikit/SDL_uikitopengles.m:114
#15 0x0015078f in SDL_GL_CreateContext at /Users/aardappel/lobster/external/SDL-2.0.0-7046/Xcode-iOS/SDL/../../src/video/SDL_video.c:2666
#16 0x000d8c5c in SDLInit(char const*, vec<int, 2>&) at /Users/aardappel/lobster/dev/xcode/lobster/../../src/sdlsystem.cpp:193
This lets us change things like this...
if (Failed) {
SDL_SetError("We failed");
return -1;
}
...into this...
if (Failed) {
return SDL_SetError("We failed");
}
Fixes Bugzilla #1778.
It's a long-dead platform, and we don't have any way to build for, test, or
maintain it, so there's no sense in doing acrobatics to support it.
If you need Windows CE support, use SDL 1.2. If you need Windows Phone support,
send SDL 2.0 patches for the newer Windows Mobile platform.
Gabriel Jacobo 2011-12-23 12:55:11 PST
The attached files provide some improvement over the current handling of
pause/resume in Android.
- I disabled the exit(status) instruction in SDL_main as that makes the entire
app instead of the SDL thread exit (while not needed for pause/resume it is
needed for Live Wallpapers, an SDLActivity for which I'll upload in a separate
bug).
- Added nativePause and nativeResume which basically just mark the window as
visible/hidden, something that the end user needs to take into consideration
(ideally pausing the event loop).
Also, this arrangement creates a new GL context when needed, which at least in
my test system is every time you go away from the app and come back to it. So,
this means that the textures need to be generated again after resuming (a
problem the end user didn't have before because the app exited completely when
it should've been pausing). I'd like to know if there's a standard way of
letting the user know that the GL context has changed and that he needs to
refresh his textures, or if this is out of the scope of the library and each
user handles it in their own way (I don't know how/if this same thing is
handled in the iPhone backend, but it would be wise to try to imitate that).
Gabriel Jacobo 2011-12-23 12:57:10 PST
Also, in the SDLActivity the EGL handling code is moved up to the Activity from
the Surface code, as I think it is possible (in theory) that the surface is
destroyed temporarily while the context remains alive (though in practice in my
test system this is not the case)
If a non-console Windows SDL program has a non-quoted 0th argument followed
optionally by more non-quoted arguments and then by an empty quoted argument,
it will crash (attempts to dereference a NULL pointer).
In other words, something like this:
test.exe [non-quoted args] "" [...]
The fix is a one-liner in ParseCommandLine() of
src/main/win32/SDL_win32_main.c.
You can test this with any non-console SDL program on windows like this:
1) Open a console (cmd.exe)
2) Launch the program in one of the following ways:
program ""
program arg1 ""
program arg1 "" arg3
These will not cause a crash:
"program" [...]
program "arg1" ""
When a Windows program is launched from Explorer, its 0th argument seems to
always be quoted, so it won't be a problem in that case.
I've tested this on Windows XP SP3 and Windows 7.
