The definition of 'thread' for one library conflicts with Boost library boost::thread

[Kadence]

I'm having issues because I am using the Boost library, but another library I am using for this project is #define'ing the term 'thread' as well. And addressing the boost thread as boost::thread in my code doesn't help. Here is what the other library's definitino is:

#if defined(_MSC_VER)
#  define thread __declspec( thread )
#else

#  define thread

This leads to errors like the below:

13>c:\program files (x86)\boost\boost_1_44\boost\thread\detail\thread.hpp(111): warning C4038: ' __declspec(thread)' : illegal class modifier
13>c:\program files (x86)\boost\boost_1_44\boost\thread\detail\thread.hpp(113): error C2059: syntax error : '__declspec(thread)'
13>c:\program files (x86)\boost\boost_1_44\boost\thread\detail\thread.hpp(113): error C2238: unexpected token(s) preceding ';'
13>c:\program files (x86)\boost\boost_1_44\boost\thread\detail\thread.hpp(114): warning C4042: 'unnamed-parameter' : has bad storage class
13>c:\program files (x86)\boost\boost_1_44\boost\thread\detail\thread.hpp(114): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int

Lines 110 to 114 in boost/thread.hpp are:

class BOOST_THREAD_DECL thread
    {
    private:
        thread(thread&);
        thread& operator=(thread&);

Any line with contains the term 'thread' in thread.hpp gives errors.

I am temporarily dealing with this error by changing all 'thread' terms in the other library to 'otherthread'. But I don't want to edit the source of the other library, because it would break or conflict with future updates/patches/extensions and such of this other library. Is there any other way I can deal with this conflict?

[jonsca]

I'm not sure if this will work, but try referring to the global one as ::thread and the Boost one as Boost::thread .

Edit: no, the more I think of it, the even less I think that will do it because the global one is a define, you're not really calling it anywhere. Sorry, wish I could have been more help. I was thinking about reordering the header files, but I think that might only be a patch fix. Doubtless you probably googled about combining this library with boost, but someone has to have encountered this before.

[Kadence]

Thank you for the effort :) Yes I had googled for this problem, but it is a niche poker simulation library so I don't think too many people actively use it.

[L7Sqr]

Any chance you can wrap the library headers in a separate namespace? Something like:

// in foo.hh
class Foo {};

// in foo.cc
namespace hidden {
#include "foo.hh"
}

int main () {
   Foo foo1; // Fail do to namespace wrap
   hidden::Foo foo2; // works as you would expect
   // ...
}

[Kadence]

Any chance you can wrap the library headers in a separate namespace? Something like:

That's a very interesting idea, thanks. I edited my main.cpp and wrapped the #include for the other library's headers inside a namesapce.

I'm getting less errors now (I don't get the errors for boost/thread.hpp anymore) but I'm still getting the following errors for the file with the main program:

12>c:\sim\examples\main.cpp(270): error C2589: '__declspec' : illegal token on right side of '::'
12>c:\sim\examples\main.cpp(270): error C2143: syntax error : missing ';' before '::'
12>c:\sim\examples\main.cpp(272): error C2065: 'workerThread' : undeclared identifier
12>c:\sim\examples\main.cpp(272): error C2228: left of '.join' must have class/struct/union

For the following lines:

boost::thread workerThread(worker);
	printf("Joining...\n");
	workerThread.join();

Looks like the compiler is still confusing this thread term with the other one, as it's not accepting the boost:: prefix.

[mike_2000_17]

Well, first of all, my recommendation would be to throw away that incredibly stupid library that does this. I can't comprehend how retarded somebody must be to think that making a #define with the name "thread" is not going to cause tremendous name-clashes.

Anyways, if you really have to use it, you can undefine the define after including the other library. As so:

#include "other_stupid_library.h"
#ifdef thread
#undef thread
#endif

#include <boost/thread/thread.hpp>

//....

That should solve your problem.

[jonsca]

Anyways, if you really have to use it, you can undefine the define after including the other library.

I had thought about that too, but what if some of the functions in the code depend on that symbol? Does it not matter by that point?

(sorry @OP to inject a couple of my own questions here, but since we're talking about it...)

[mike_2000_17]

>>what if some of the functions in the code depend on that symbol?

If the OPs code is not using the code in a way that requires this "thread" #define, it should be fine. In other words, if the use of this keyword is only restricted, in the code, to the other library's header files, it should be fine. Otherwise, he will have to play a little game of #defining and #undefining the keyword around every use of it. I'm pretty sure it will be Ok.

[jonsca]

Thanks.

Otherwise, he will have to play a little game of #defining and #undefining the keyword around every use of it.

Yes, that would be painful.

[Kadence]

Thanks, the #undef solution works :)