[polygon] Compiling polygon under Windows

Hello,
I have been compiling boost::polygon under Windows (VS2008, MSVC9.0
specifically) and have run into a minor problem with boost::polygon's
detection of Microsoft's compiler. Specifically, it tests for the
WIN32 preprocessor define instead of _WIN32. WIN32 isn't actually
defined by the compiler, but by windows.h, and not all translation
units actually need to include that header. _WIN32 is defined by the
compiler, and boost has the similar BOOST_MSVC preprocessor define
which could also be used.
While there is some disagreement among the existing boost libraries
about the best mechanism to check this, some check _WIN32, some check
BOOST_MSVC, and some check both or others at the same time.
I propose the following patch to the 1.45.0 boost::polygon sources to
make the detection of the MSVC compiler more robust.
Regards,
Josh Pieper
Index: boost/polygon/gtl.hpp
===================================================================
--- boost/polygon/gtl.hpp
+++ boost/polygon/gtl.hpp
@@ -12,7 +12,7 @@
#pragma warning (disable:1125)
#endif
-#ifdef WIN32
+#ifdef _WIN32
#pragma warning( disable: 4996 )
#pragma warning( disable: 4800 )
#endif
Index: polygon/isotropy.hpp
===================================================================
--- boost/polygon/isotropy.hpp
+++ boost/polygon/isotropy.hpp
@@ -48,7 +48,7 @@
#include

When creating a c++ console solution/project in msvc, by default defines WIN32 - this seems to be the case for both msvc 2008 & 2010. More information: http://stackoverflow.com/questions/662084/whats-the-difference-between-the-w... On 29/11/2010 6:17 AM, Josh Pieper wrote:
I propose the following patch to the 1.45.0 boost::polygon sources to make the detection of the MSVC compiler more robust.
Regards, Josh Pieper

Josh Pieper wrote:
Hello,
I have been compiling boost::polygon under Windows (VS2008, MSVC9.0 specifically) and have run into a minor problem with boost::polygon's detection of Microsoft's compiler. Specifically, it tests for the WIN32 preprocessor define instead of _WIN32. WIN32 isn't actually defined by the compiler, but by windows.h, and not all translation units actually need to include that header. _WIN32 is defined by the compiler, and boost has the similar BOOST_MSVC preprocessor define which could also be used.
While there is some disagreement among the existing boost libraries about the best mechanism to check this, some check _WIN32, some check BOOST_MSVC, and some check both or others at the same time.
I propose the following patch to the 1.45.0 boost::polygon sources to make the detection of the MSVC compiler more robust.
Regards, Josh Pieper
Index: boost/polygon/gtl.hpp =================================================================== --- boost/polygon/gtl.hpp +++ boost/polygon/gtl.hpp @@ -12,7 +12,7 @@ #pragma warning (disable:1125) #endif
-#ifdef WIN32 +#ifdef _WIN32 #pragma warning( disable: 4996 ) #pragma warning( disable: 4800 ) #endif Index: polygon/isotropy.hpp =================================================================== --- boost/polygon/isotropy.hpp +++ boost/polygon/isotropy.hpp @@ -48,7 +48,7 @@ #include
#else -#ifdef WIN32 +#ifdef _WIN32 #define BOOST_POLYGON_MSVC #endif #ifdef __ICC @@ -290,7 +290,7 @@
template <typename T> struct gtl_if { -#ifdef WIN32 +#ifdef _WIN32 typedef gtl_no type; #endif };
I can fix this for the next release, however, for the second change it should actually use BOOST_POLYGON_MSVC and not _WIN32. It was an oversight on my part that it was using the WIN32 instead of BOOST_POLYGON_MSVC macro. It was a bug fix I added for older versions of the ICC compiler (and EDG frontend in general) which weren't doing SFINAE properly in a way that was mutually exclusive with the way MSVC 7.1, 8 and 9 doesn't do SFINAE properly. Gcc worked either way so I singled out MSVC for the special behavior so that gcc, icc and all compilers that might use old versions of EDG frontend that I don't know about would work by default. Apparently when I made the fix I used the wrong macro name. I doubt you are using Polygon with BOOST_POLYGON_NO_DEPS defined, so it is the second instance of WIN32 that was causing you trouble and it was my error in using WIN32 instead of BOOST_POLYGON_MSVC that caused you the problem. You should see a commit to trunk soon. Thanks, Luke

On Mon, Nov 29, 2010 at 11:31:03AM -0800, Simonson, Lucanus J wrote:
I can fix this for the next release, however, for the second change it should actually use BOOST_POLYGON_MSVC and not _WIN32. It was an oversight on my part that it was using the WIN32 instead of BOOST_POLYGON_MSVC macro. It was a bug fix I added for older versions of the ICC compiler (and EDG frontend in general) which weren't doing SFINAE properly in a way that was mutually exclusive with the way MSVC 7.1, 8 and 9 doesn't do SFINAE properly. Gcc worked either way so I singled out MSVC for the special behavior so that gcc, icc and all compilers that might use old versions of EDG frontend that I don't know about would work by default. Apparently when I made the fix I used the wrong macro name. I doubt you are using Polygon with BOOST_POLYGON_NO_DEPS defined, so it is the second instance of WIN32 that was causing you trouble and it was my error in using WIN32 instead of BOOST_POLYGON_MSVC that caused you the problem. You should see a commit to trunk soon.
Surely Boost.Config contains Boost-global functionality for platform detection? -- Lars Viklund | zao@acc.umu.se

Lars Viklund wrote:
On Mon, Nov 29, 2010 at 11:31:03AM -0800, Simonson, Lucanus J wrote:
I can fix this for the next release, however, for the second change it should actually use BOOST_POLYGON_MSVC and not _WIN32. It was an oversight on my part that it was using the WIN32 instead of BOOST_POLYGON_MSVC macro. It was a bug fix I added for older versions of the ICC compiler (and EDG frontend in general) which weren't doing SFINAE properly in a way that was mutually exclusive with the way MSVC 7.1, 8 and 9 doesn't do SFINAE properly. Gcc worked either way so I singled out MSVC for the special behavior so that gcc, icc and all compilers that might use old versions of EDG frontend that I don't know about would work by default. Apparently when I made the fix I used the wrong macro name. I doubt you are using Polygon with BOOST_POLYGON_NO_DEPS defined, so it is the second instance of WIN32 that was causing you trouble and it was my error in using WIN32 instead of BOOST_POLYGON_MSVC that caused you the problem. You should see a commit to trunk soon.
Surely Boost.Config contains Boost-global functionality for platform detection?
Indeed it does, and by default BOOST_POLYGON_MSVC is defined if BOOST_MSVC is defined. Only if the user defines BOOST_POLYGON_NO_DEPS does Polygon attempt to compile without any dependency on boost what-so-ever and in that case I set BOOST_POLYGON_MSVC if I detect WIN32 macro is defined.
#ifndef BOOST_POLYGON_NO_DEPS
#include
participants (4)
-
Arash Partow
-
Josh Pieper
-
Lars Viklund
-
Simonson, Lucanus J