hello,

I'm trying to make a game with allegro, and I need threads. I've found the boost library but it seems that there is a problem between allegro and boost ...

when I build my project I've got this kind of errors :

1>c:\program files\boost\boost_1_38\boost\cstdint.hpp(193) : warning C4114: même qualificateur de type utilisé plusieurs fois
1>c:\program files\boost\boost_1_38\boost\cstdint.hpp(193) : error C2632: 'char' ne peut pas être suivi de 'char'
1>c:\program files\boost\boost_1_38\boost\cstdint.hpp(193) : warning C4091: 'typedef ' : ignoré à gauche de 'signed char' quand aucune variable n'est déclarée
1>c:\program files\boost\boost_1_38\boost\cstdint.hpp(196) : warning C4114: même qualificateur de type utilisé plusieurs fois

that only do it when the include of allegro is before the boost one ...But I don't know how to control exactly the order of inclusion in my project (I've got a lot of class using both allegro and boost ...)

Has someone a solution to solve this or does anyone know an other library for thread ?

(and excuse me for my english ...^^')

cstdint.hpp, not cstdlib.

This is pretty much a lesson in why you always, always, always should use typedefs for types instead of #defines.

In Allegro's astdint you have:

#define int8_t       signed char
#define uint8_t      unsigned char

So then boost's cstdint implementation attempts to do:

typedef signed char     int8_t; // line 193
typedef unsigned char   uint8_t; // line 196

But unforunately the compiler sees

typedef signed char signed char;
typedef unsigned char unsigned char;

Oopsie.

Ah, my bad.

I think you should be able to work around it by #undef'ing the troublesome macros between includes (AFAIK, those macros are internal and not needed by external code)...

#include <allegro.h>

#undef int8_t
#undef uint8_t
...

#include "Construction.h"

You'll have to see if it works or wait for somebody to correct me. Perhaps somebody should patch Allegro to use typedefs instead of macros. Or to at least use more unique names (perhaps Allegro 5 is already doing this? No, no, it's still there...).

it works !!! thank you very much !!!^^

I hav had to add this lines too :
#undef intmax_t
#undef uintmax_t
#undef int64_t
#undef int_least64_t
#undef int_fast64_t
#undef uint64_t
#undef uint_least64_t
#undef uint_fast64_t

but now it works fine and allegro is always ok ^^
thanks both of you ^^

Er... Use an incorrect method so that people will be able to fix the problems caused by use of said incorrect method? Does not compute.

Just do it right to begin with - a few lines of code in astdint.h and a few minutes with a halfway decent refactoring tool would fix the whole problem.

Instead of overwriting the standard types, you create your own types which wrap around them - you don't clash with the standard names so it doesn't matter if the user has a 3rd party implentation of those standard types.

Change astdint.h to be along the lines of:

And refactor existing code to use the new types.

Hell, I just did the work for you and it took me all of one minute. Gonna have to go rest now after that strenuous exertion.

You know, if you really wanted to be a lazy sod you could just undef all the macros at the end of allegro.h. But I guess then you couldn't take your awesome stand against teh evil Microsoft.

I'd probably keep the current behavior and add something like:

#define ALLEGRO_NO_STD_TYPES
#include <allegro.h>

That's just a laughable argument. No one is relying on Allegro to define integer types for them (nor should they be). The entire problem here is that you're taking things that are for internal use and exposing them to the user, resulting in behavior that the user does not expect (redefinition of standard types).

The problem is that Allegro can't undefine them at the bottom of it's header file(s) because I'm sure the Allegro header files are also needed by Allegro's source files, which probably expect those macros to still exist. The only way for Allegro to remove them is to create a user-space header file that wraps around the original, as Speedo suggested earlier. That, or just define Allegro specific types that are unlikely to collide so this problem isn't likely to come up.

They reside in the boost namespace.

I like Matthew Leverton's solution, just wrap the necessary emulation headers with that macro and let people who use sub-standard compilers define the macro. Naturally, it should be documented. Or perhaps just let people know the name of the header guard macro for those files (I assume defining it would have the same effect).

That quite frankly is a load of bull. Most libs but Allegro in particular expend a lot of effort to maintain support for antiquated compilers and platforms that pretty much no one in their right mind is going to use today. But when we start talking about 30 second fix for one of your most popular platforms, the response is "screw em"? Yeah, no ulterior motives involved there.

Besides, your argument is moot. A quick glance at the Allegro platform headers shows that at least 4 of the supported compilers do not have support for C99 int types.