Why doesn't SFML use ALuint to identify sources/buffers?

[Symphonym]

Just something that struck me while looking through the SFML source since it's an issue I'm currently having. I find myself trying to wrap API defined types in small classes in order to hide OpenAL dependencies which I feel will get out of hand when I get to writing OpenGL code. But SFML just uses a pointer to a regular unsigned int where the  OpenAL API expects an ALuint pointer, would this be safe on all platforms?

Just to get another idea of what I'm confused about; I have a Color class with floats as each of its components that I'm using to set the OpenGL clear color. Would this be safe since glClearColor expects GLfloat's and not regular float's? The general question is that I'm wondering how much I have to use the types defined by an API since it seems that SFML doesn't use them with every function call to the API using the types.

[Laurent]

Use the API's types as much as you can. But if, like SFML, you can't expose these types in public headers (because you don't want to expose GL / AL headers to the user), then replacing them with their native equivalent is the only choice you have.

To know whether it is safe or not, you have to look at the definition of the type. Since OpenGL and OpenAL are specifications, not libraries, you have to look at the spec documents. For OpenGL, types are defined by a fixed size and a description. So theoretically it would be safer to use sf::Uint32 for GLuint, for example. In practice this is not a problem, as long as you're playing with "common" processors.

[Symphonym]

Use the API's types as much as you can. But if, like SFML, you can't expose these types in public headers (because you don't want to expose GL / AL headers to the user), then replacing them with their native equivalent is the only choice you have.

To know whether it is safe or not, you have to look at the definition of the type. Since OpenGL and OpenAL are specifications, not libraries, you have to look at the spec documents. For OpenGL, types are defined by a fixed size and a description. So theoretically it would be safer to use sf::Uint32 for GLuint, for example. In practice this is not a problem, as long as you're playing with "common" processors.

Ah well that makes sense. And going by http://www.openal.org/documentation/openal-1.1-specification.pdf would mean that ALuint and GLuint are equal, thus anything representing an unsigned 32-bit integer would be safe to use I assume?

Also, "then replacing them with their native equivalent is the only choice you have". With the example of OpenAL sources/buffers, wouldn't that be unsafe if "unsigned int" on that platform isn't an unsigned 32-bit integer?

Finally, how I tend to see it at the moment I use native types (if I can't use the API  types) in an API function if the function wants the values passed by value, seeing how as far as I know whatever values I pass will get converted to the type of that parameter (presumably an API type). Whereas functions wanting a pointer, such as alGenSources or glGenBuffers is where you should use the API defined types since you're giving the API a value which it expects to be exatcly of X bits size. Would this be a fair/logical assumption?

[Laurent]

With the example of OpenAL sources/buffers, wouldn't that be unsafe if "unsigned int" on that platform isn't an unsigned 32-bit integer?

That wouldn't match. Whether it is safe or not depends on what you do with it.

Finally, how I tend to see it at the moment I use native types (if I can't use the API  types) in an API function if the function wants the values passed by value, seeing how as far as I know whatever values I pass will get converted to the type of that parameter (presumably an API type). Whereas functions wanting a pointer, such as alGenSources or glGenBuffers is where you should use the API defined types since you're giving the API a value which it expects to be exatcly of X bits size. Would this be a fair/logical assumption?

Arguments passed by value is where you can get runtime problems. If the size doesn't match, and you're using a value which is outside the range of the native type, then it will be converted to some other incorrect value. For pointers you'll get compiler errors so that's a lot easier to handle.

[Symphonym]

Whether it is safe or not depends on what you do with it.

This is what I'm having trouble understanding, what operations would be considered "Unsafe"? Since I regularly see projects passing native types to OpenAL/GL but I can't really see any pattern for "safe usage" other than native types are used where an API defined type can't be used without creating dependencies (a header file included by the client). I realize this may not really be too specific to SFML anymore but think you'd be able to give me an idea of when usage of native types in OpenAL/GL functions is considered safe/okay?

[Laurent]

It would be unsafe if you compiled on an exotic platform, where the chosen native type wouldn't match the specification. This is very unlikely to happen, unless you're doing very specific stuff, so you can consider that it is always safe. That's what I do, and I've never heard anyone reporting problems with that in 7 years of SFML.

[Symphonym]

It would be unsafe if you compiled on an exotic platform, where the chosen native type wouldn't match the specification. This is very unlikely to happen, unless you're doing very specific stuff, so you can consider that it is always safe. That's what I do, and I've never heard anyone reporting problems with that in 7 years of SFML.

So with the example of unsigned ints, you're assuming no one is compiling on a platform on which sizeof(unsigned int) != sizeof(GLuint)   or ALuint for that matter.  Or in the event that somebody does, hope that it doesn't cause any issues?

A quick google gives http://stackoverflow.com/questions/12285502/do-i-have-to-use-opengls-datatypes-glint-clchar-for-a-cross-platform-ga and http://stackoverflow.com/questions/8932912/whats-the-advantage-of-using-gluint-instead-of-unsigned-int both of which makes it sound like differences in native type sizes aren't that uncommon.

But to wrap this up, seeing how I already use C++11 should I be using the fixed size types that the std provides if I want to stay clear of "possible" buggy behaviour. Or should I stick to using API defined types in the .cpp files where their usage doesn't add dependencies or hurt the overall codebase, and native types in publicy exposed header files where I need to store identifiers/similar to things in external API's/specifications/libraries?

[Laurent]

both of which makes it sound like differences in native type sizes aren't that uncommon.

It is not uncommon in the embedded world for example. But in 32/64 bits processors of today's computers, int and unsigned int are always 32 bits. For its typedefs (sf::Uint8 etc.), SFML doesn't even bother to do any test, and so far it has always worked on all the platforms where SFML is being used.

But yes, if you have access to standard fixed-size types, this will be a much better option since it will more closely match the AL/GL specification.

In .cpp and private headers, use AL/GL types since there's nothing that prevents you to do so.