I just upgraded to Boost 1.35, and I now have a major problem with windows.h, thanks to the Boost.Threads library now invoking Boost.DateTime which on Windows #includes <windows.h>. Besides the min and max macros, there are other problems, like the fact that one of the platform headers does this: #define small char A third party library that I am using has a class called small. Oops. There are very, very many of these things. I'm afraid I am going to have to go back to 1.34 indefinitely. Google pulls up a lot of messages from other users having these troubles. I don't know very much about the Boost.DateTime architecture - I have used the threading library for years in its older version, but never the date/time library - but to the DateTime developers I ask: Is there any possible way that this could be reworked in the future to avoid bringing windows.h into the user's world? The macros and namespace pollution are a very serious problem. Defining NOMINMAX helps a little, but on things like the "small" macro I'm afraid I'm stuck. I see from mailing list posts that DateTime is not the only Boost library to do this, although certainly most of the libraries do not. It surprises me that Boost has such a nice policy on its own headers, yet allows implementations to do things like this. I know sometimes it is hard to avoid, but for windows.h - which is notorious for these problems - it would seem like it would be worth some contortions in the implementation to avoid this. I would be more than happy to compile and link some extra CPP files to keep the HPP files clean. To the Boost community at large I ask: What is the thinking on this? Thanks for your consideration. Brian
Brian E. Coggins wrote:
I know sometimes it is hard to avoid, but for windows.h - which is notorious for these problems - it would seem like it would be worth some contortions in the implementation to avoid this. I would be more than happy to compile and link some extra CPP files to keep the HPP files clean.
Seconded. I've had to wrap some places where I use boost, just to isolate them from other parts of the codebase. Rather than thousands of developers individually doing this, it would seem preferable and more efficient for boost to do it. Matt
Brian E. Coggins wrote:
I just upgraded to Boost 1.35, and I now have a major problem with windows.h, thanks to the Boost.Threads library now invoking Boost.DateTime which on Windows #includes <windows.h>. Besides the min and max macros, there are other problems, like the fact that one of the platform headers does this:
#define small char
A third party library that I am using has a class called small. Oops. There are very, very many of these things. I'm afraid I am going to have to go back to 1.34 indefinitely.
Doesn't changing include order settle the problem?
Google pulls up a lot of messages from other users having these troubles. I don't know very much about the Boost.DateTime architecture - I have used the threading library for years in its older version, but never the date/time library - but to the DateTime developers I ask: Is there any possible way that this could be reworked in the future to avoid bringing windows.h into the user's world? The macros and namespace pollution are a very serious problem. Defining NOMINMAX helps a little, but on things like the "small" macro I'm afraid I'm stuck.
I see from mailing list posts that DateTime is not the only Boost library to do this, although certainly most of the libraries do not. It surprises me that Boost has such a nice policy on its own headers, yet allows implementations to do things like this. I know sometimes it is hard to avoid, but for windows.h - which is notorious for these problems - it would seem like it would be worth some contortions in the implementation to avoid this. I would be more than happy to compile and link some extra CPP files to keep the HPP files clean. To the Boost community at large I ask: What is the thinking on this?
IMO, the best solution would be to create windows.hpp that would redefine frequently used windows.h parts in some namespace within boost. Something like that is already done in Boost.Thread and interlocked.hpp, all this stuff just needs to be gathered somewhere to be used in different libraries. Header-only libraries, that is. As for compiled libraries, I see no problems with leaving headers of such libraries windows.h-free and using genuine windows.h in their cpp files.
A third party library that I am using has a class called small. Oops. There are very, very many of these things. I'm afraid I am going to have to go back to 1.34 indefinitely.
Doesn't changing include order settle the problem?
That might work. The problem is that I include boost/thread.hpp in quite a few of my own header files, so it is a little tricky to make sure it doesn't get included before the other library. I might give that a try, but it will need some reengineering.
Andrey Semashev wrote:
Brian E. Coggins wrote:
like the fact that one of the platform headers does this:
#define small char
A third party library that I am using has a class called small. Oops. There are very, very many of these things. I'm afraid I am going to have to go back to 1.34 indefinitely.
Doesn't changing include order settle the problem?
Not if there's a name conflict between macros and something you actually use (as opposed to something that's merely defined). Matt
Brian E. Coggins schrieb:
I just upgraded to Boost 1.35, and I now have a major problem with windows.h, thanks to the Boost.Threads library now invoking Boost.DateTime which on Windows #includes <windows.h>. Besides the min and max macros, there are other problems, like the fact that one of the platform headers does this:
I've got a ticket open for this: http://svn.boost.org/trac/boost/ticket/1740 Cheers, Anteru
participants (4)
-
Andrey Semashev -
Anteru -
Brian E. Coggins -
Matt Gruenke