Skip to main content
GameDev.net gamedev.net
🔒 Locked

stdint.h and library conflicts

Started by sb01234 Apr 11, 2009 at 3:53 AM 1 replies 4.4k views
Original Post
sb01234
sb01234
A lot of 3rd party libraries define their own known precision data types similar to what the C99 standardized stdint.h (cstdint for C++) does. Often the typedefs aren't exactly identical and so compile errors arise when a compilation unit needs to include headers for two such conflicting libraries. A recent example I came across when using SDL and Assimp together (it doesn't matter which order I include the files, both orderings cause compile errors):

#include <include/assimp.hpp>
#include <SDL/SDL.h>
int main(int argc, char *argv[]) {
	return 0;
}





c:\external\include\include\compiler\pstdint.h(380) : error C2371: 'uint32_t' : redefinition; different basic types
        c:\external\include\sdl\sdl_config_win32.h(38) : see declaration of 'uint32_t'
c:\external\include\include\compiler\pstdint.h(410) : error C2371: 'int32_t' : redefinition; different basic types
        c:\external\include\sdl\sdl_config_win32.h(37) : see declaration of 'int32_t'
What is the recommended way of handling this type of problem? What is the responsibility of the library maker, and what is the responsibility of the user, in order to solve it?
http://www.better-than-real.net/sb/
MaulingMonkey
MaulingMonkey
In C++ you typically throw everything into namespaces so there's no conflict. In C you typically prefix everything with your library name (e.g. SDL_SetVideoMode) so there's no conflict.

It sounds like neither has taken the proper route here. Potential hackarounds include #define uint32_t theirlib_uint32_t #include <...> #undef uint32_t and similar evil hacks.
SiCrane
SiCrane
One approach is to try wrapping inclusions of those headers in namespaces. I find this to be fragile and annoying, but other people swear by it. Another option is to just avoid including both headers in the same source files; create design firewalls around the functionality of all the relevant libraries so that any source file that requires functionality of either doesn't need to know about the implementation details of both libraries.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.