troubles with boost::thread and FreeImage

Started by
13 comments, last by cignox1 15 years, 9 months ago
Hi all, my problem is very easy to explain: when including <FreeImage.h> and <thread.hpp> from boost the compiler issues a few errors:
Quote: Error 9 error C2061: syntax error : identifier 'FILETIME' C:\Users\alessandro.caviola.EMDSESRL\Documents\Visual Studio 2005\Projects\boost_1_35_0\boost\date_time\microsec_time_clock.hpp 152 Error 11 error C4430: missing type specifier - int assumed. Note: C++ does not support default-int C:\Users\alessandro.caviola.EMDSESRL\Documents\Visual Studio 2005\Projects\boost_1_35_0\boost\date_time\filetime_functions.hpp 36 Error 12 error C2143: syntax error : missing ',' before '&' C:\Users\alessandro.caviola.EMDSESRL\Documents\Visual Studio 2005\Projects\boost_1_35_0\boost\date_time\filetime_functions.hpp 36
Someone know the reason and know a way to fix them? Thank you!
Advertisement
I thought it would have been useful to add that the problem appears only when both files are included, but everythings works fine with only one of them...
My guess is that FreeTime.h does some ugly macro voodoo that causes a collision with some of the stuff in thread.hpp or any of the headers included by thread.hpp.

Can you post the content of your FreeTime.h file?
Thank you for answering, but there is no FreeTime.h... do you mean FreeImage? It is the free open source library to load images...
I don't have it right now (i have it at work) but thank you... I will download it and will try to give it a look...
Any other idea?

Thank you!
Quote:Original post by cignox1
Thank you for answering, but there is no FreeTime.h... do you mean FreeImage?


Uh yeah, that one. Sorry, I need sleep. ;p

Some more infos: that problem is caused by the fact that apparently if I include <FreeImage.h> before <thread.hpp>, the FILETIME structure and a couple of functions are seen by the compiler as not defined. Both FILETIME and the functions are defined a file included by <windows.h>.
In short, <FreeImage.h> does something that makes symbols defined in windows.h no longer avilable.

Note that if I add:

typedef struct _FILETIME {  DWORD dwLowDateTime;  DWORD dwHighDateTime;} FILETIME,  *PFILETIME;


just before the thread.hpp inclusion, then at least the error regarding that structure goes away.

Unlukily, I cannot move the <thread.hpp> on the top of the file, because it inlcudes windows.h and this generates a couple of errors on a std::numeric_limits<float>::max(); call later in my code.

Do you have any idea about what causes this, what should I look for in the FreeImage header, and how to solve this?
#undef min
#undef max

(and kill a few C standard comitee members).
Thank you: I already tried it, but more errors appeared elsewhere in my code. I tried placing the undef just before the each occourence of max that gave the error, or only once just after the inclusion of windows.h. The problems are still there...

Ok, my fault. I thought that the other errors were caused by the same issue (max and min macro) because they happened to appear where max and min tokens were used.
Instead, I forgot that near and far are keyword in msvc :-( so if windows.h is included they appeared where they shouldn't...

Thank you.

By the way, for those interested, I used the
#define NOMINMAX

macro just before including windows.h instead than undefining max and min.
I'm assuming FreeImage.h is this one.

It's doing some nasty stuff in there with copying and pasting bits of the windows headers (look for #ifndef _WINDOWS_). Note that _WINDOWS_ is the same define used in the real Windows.h file that comes in the Platform SDK so it'll break almost any other windows code if it's included before the real windows.h (and will probably break freeimage if included after the real windows.h).

I'd suggest removing that section from their header file, and including windows.h instead. You'll probably also need to make some more adjustments to it get them both to compile.

Alternatively find a better library to use in place of FreeImage - if that header file is anything to go by you may well run into more problems with it.

This topic is closed to new replies.

Advertisement