Quoth Sam Lantinga , on 2011-01-16 15:56:40 -0800:
We have a few options:
Never include windows.h and always use SDL library atomic functions on
windows
Never include windows.h and transparently use Windows atomic operation
functions if windows.h has already been included
Include windows.h and move SDL_atomic.h out of SDL.h so it’s not
automatically included in most games’ source
Conditionally include windows.h, if external code has requested it via #define
I think I’m leaning towards #3, but what would other people prefer?
I like #3 as well, even aside from the whole header dependency issue;
it seems parallel to at least the 1.2 usage of SDL_opengl.h. Atomic
operations are somewhat specialized, and someone who’s looking for
them should be looking for them specifically, so it makes sense for
them to be a bit out of the way.
A hybrid approach might work, though it’d be more complicated: provide
wrappers inside the SDL library for the Interlocked* operations (which
is what I’m assuming you mean by “Windows atomic operations”), then
use an externally-defined request macro to choose between those and
inline definitions that require windows.h.
It depends on the extent of what you need from windows.h, but could you
not just copy and paste what you need from the header to the point
where you would have included it, thereby avoiding windows.h pollution?
I know it’s not exactly C programming best practice, but if what you
want is relatively simple and unchanging it might be worth it to
sidestep the issue.
Otherwise, yep, option #3.On Sun, 16 Jan 2011 15:56:40 -0800 Sam wrote:
In order to get the Windows atomic operations in SDL_atomic.h, we
need to include windows.h, which can break code that isn’t expecting
it.
I think I’m leaning towards #3, but what would other people prefer?
I could, but windows.h has some special cases to redirect to compiler
intrinsics that I don’t want to replicate or make assumptions about.On Sun, Jan 16, 2011 at 4:18 PM, Tim Angus wrote:
On Sun, 16 Jan 2011 15:56:40 -0800 Sam wrote:
In order to get the Windows atomic operations in SDL_atomic.h, we
need to include windows.h, which can break code that isn’t expecting
it.
I think I’m leaning towards #3, but what would other people prefer?
It depends on the extent of what you need from windows.h, but could you
not just copy and paste what you need from the header to the point
where you would have included it, thereby avoiding windows.h pollution?
I know it’s not exactly C programming best practice, but if what you
want is relatively simple and unchanging it might be worth it to
sidestep the issue.
Wouldn’t it be possible to include it in SDL_atomic.c instead?
I know that this has been decided on #3 already … but… I wanna echo
Nathan’s query.
How much of the existing SDL API has system specific stuff in #include’s
that affect applications ? IE: when I work with mutexes and threads and
stuff, I don’t ever access / work with regular posix mutex stuff… I’m
doing everything entirely through the SDL wrappers. Does SDL.h or
subsequent headers go ahead and #include all the platform specific stuff as
well when building an application ?
-WillOn Sun, Jan 16, 2011 at 9:47 PM, Nathaniel J Fries wrote:
No, the idea is to #define SDL functions as native (often compiler intrinsic
or assembly) functions for speed where possible. Since the atomic
operations are all about fast concurrent programming, this is a case where
you want as much speed as you can possibly get.
I ended up going with #3, but I added a #define that you can enable if you
want to turn that optimization off and go with the standard SDL library
functions. Those are always available for applications that want them,
regardless of what’s happening in the SDL public API header.
See ya!On Sun, Jan 16, 2011 at 7:47 PM, Nathaniel J Fries wrote:
Wouldn’t it be possible to include it in SDL_atomic.c instead?
No, the idea is to #define SDL functions as native (often compiler intrinsic or assembly) functions for speed where possible.? Since the atomic operations are all about fast concurrent programming, this is a case where you want as much speed as you can possibly get.
In that case, couldn’t you just include the add the prototypes for the intrinsics at the top of the header file?------------------------
EM3 Nathaniel Fries, U.S. Navy
They’re redirected to platform-specific compiler intrinsics under some
circumstances. I’d rather let Microsoft pick the best implementation for
the environment. :)On Sun, Jan 16, 2011 at 8:59 PM, Nathaniel J Fries wrote:
Sam Lantinga wrote:
No, the idea is to #define SDL functions as native (often compiler
intrinsic or assembly) functions for speed where possible. Since the atomic
operations are all about fast concurrent programming, this is a case where
you want as much speed as you can possibly get.
In that case, couldn’t you just include the add the prototypes for the
intrinsics at the top of the header file?
I could, but windows.h has some special cases to redirect to
compiler intrinsics that I don’t want to replicate or make
assumptions about.
Ah, fair enough; probably not a smart move then :).
However, from the other thread:On Mon, 17 Jan 2011 00:30:14 +0000 Tim wrote:
On Sun, 16 Jan 2011 16:23:27 -0800 Sam wrote:
On Mon, 17 Jan 2011 18:57:25 +0200 M?rti?? wrote:
With Visual Studio C++ compiler you can use #include <intrin.h> to use
InterlockedXYZ API. No need to include <windows.h>. And this
<intrin.h> header doesn’t include <windows.h>!
Ah, good catch. It looks like these work in both x86 and x64 environments.
I switched SDL_atomic.h to use intrin.h instead of windows.h and put it back
in SDL.h.
Thanks!On Mon, Jan 17, 2011 at 12:58 PM, Tim Angus wrote:
On Mon, 17 Jan 2011 00:30:14 +0000 Tim wrote:
On Sun, 16 Jan 2011 16:23:27 -0800 Sam wrote:
I could, but windows.h has some special cases to redirect to
compiler intrinsics that I don’t want to replicate or make
assumptions about.
Ah, fair enough; probably not a smart move then :).
However, from the other thread:
On Mon, 17 Jan 2011 18:57:25 +0200 M?rti?? wrote:
With Visual Studio C++ compiler you can use #include <intrin.h> to use
InterlockedXYZ API. No need to include <windows.h>. And this
<intrin.h> header doesn’t include <windows.h>!
Quoth Sam Lantinga , on 2011-01-17 14:08:58 -0800:
Ah, good catch. It looks like these work in both x86 and x64 environments.
I switched SDL_atomic.h to use intrin.h instead of windows.h and put it back
in SDL.h.
I’m curious whether this will make it difficult to build SDL programs
on MinGW (and indeed whether that’s considered a target platform at
all), since the previous poster mentioned Visual C++ directly. Would
GCC intrinsics be used instead in the case of MinGW, or such?
No, I just tested it with the mingw cross-compiler environment. MinGW
provides intrin.h that supports the necessary functions.On Mon, Jan 17, 2011 at 2:18 PM, Drake Wilson wrote:
Quoth Sam Lantinga <@slouken>, on 2011-01-17 14:08:58 -0800:
Ah, good catch. It looks like these work in both x86 and x64
environments.
I switched SDL_atomic.h to use intrin.h instead of windows.h and put it
back
in SDL.h.
I’m curious whether this will make it difficult to build SDL programs
on MinGW (and indeed whether that’s considered a target platform at
all), since the previous poster mentioned Visual C++ directly. Would
GCC intrinsics be used instead in the case of MinGW, or such?
Hm. Well, with current MinGW32, I’m not seeing that header, and my
build (obviously) fails, which sucks.
I’m guessing you’re using the MinGW-W64 distribution.
Bummer, as MinGW-W64 is kind of a mess if you want a simple 32-bit
Windows compiler. I tend to stick with MinGW32 when at all possible.
For the record, I DO hope we can keep some distribution of MinGW as
a supported platform. Anything else would be really unfortunate. VC++,
while not a bad C90 compiler, simply isn’t a C99 compiler, and
that’s how I prefer to work, when at all possible.
I’ll try building using MinGW-W32 when I get a chance (assuming no one
else does it first). It does have intrin.h, so it will likely build
OK.On Mon, Jan 17, 2011 at 16:22, Sam Lantinga wrote:
No, I just tested it with the mingw cross-compiler environment.? MinGW
provides intrin.h that supports the necessary functions.
–
Do what you can, where you are, with what you have. - T. Roosevelt
I also lack intrin.h
My MinGW installation is a recent one from the official sourceforge page.
Perhaps the solution here is to just always use the SDL library functions on MinGW? Certainly not ideal, but…------------------------
EM3 Nathaniel Fries, U.S. Navy
I’d upgrade that from “unfortunate” to “disastrous”. Most of the software I
write these days has to run on Linux, Mac, and Windows (in that order of
preference). Currently I compile for Linux and Windows on my Linux machine,
using mingw32 for the Windows cross-compile. Someday I hope to figure out how
to cross-compile for OSX on Linux (might be trivially easy but I’ve not had
time to look into it).
JeffOn Monday 17 January 2011 15:07, Greg Jandl wrote:
For the record, I DO hope we can keep some distribution of MinGW as
a supported platform. Anything else would be really unfortunate.