[polygon] examplefile compilation failed
Hi Luke and polygonists! I had problems compiling the example files from the doc's main page with msvc-9. None of custom_p*.cpp examples compiled. Also the connectivity_extraction_usage.cpp example failed. (1) connectivity_extraction_usage.cpp: #include <boost/gtl/gtl.hpp> must be replaced by #include <boost/polygon/polygon.hpp> namespace gtl = boost::polygon; has to be added. (2) custom_point.cpp: compilation yields: 1>.\custom_point.cpp(75) : error C2757: 'gtl' : a symbol with this name already exists and therefore this name cannot be used as a namespace name 1>.\custom_point.cpp(77) : error C2143: syntax error : missing ';' before '<' 1>.\custom_point.cpp(77) : error C2913: explicit specialization; '::geometry_concept' is not a specialization of a class template and many errors more after replacing gtl:: by boost::polygon:: and namespace gtl { ... } by namespace boost { namespce polygon { ... } } and adding typedef int coordinate_type; to struct CPoint the code finally compiled. Are these examples intended to be excercises ;) HTH Joachim
Joachim Faulhaber wrote:
after replacing gtl:: by boost::polygon:: and namespace gtl { ... } by namespace boost { namespace polygon { ... } }
and adding
typedef int coordinate_type;
to struct CPoint
the code finally compiled. Are these examples intended to be excercises ;)
Did you realize that they are extremely challenging exercises? Replacing" namespace gtl { ... }" by "namespace boost { namespace polygon { ... } }" is correct and sufficient to make the files compile with gcc compilers. (As you can guess, this got broken when the library was renamed from gtl to boost::polygon.) The challenging part is to make the examples compile with msvc-9, by introducing the correct workarounds in the code of the library itself. I had hoped that Steven Wantanabe would try to face this challenge, because it looks as if he was the one who helped fix the other msvc issues. So I counted this compile-failure as a test coverage issue of the unit-tests in my review. Regards, Thomas
2009/8/31 Thomas Klimpel <Thomas.Klimpel@synopsys.com>:
Joachim Faulhaber wrote:
Are these examples intended to be excercises ;)
Did you realize that they are extremely challenging exercises?
Don't take my remark too seriously. I don't claim this was a big job. Nevertheless I think it is important fix those examples soon because they give a false impression to this exceptional library. Examples are important, they are read first and compiled first, when people get interested. cheers Joachim
Thomas Klimpel wrote:
Joachim Faulhaber wrote:
after replacing gtl:: by boost::polygon:: and namespace gtl { ... } by namespace boost { namespace polygon { ... } }
and adding
typedef int coordinate_type;
to struct CPoint
the code finally compiled. Are these examples intended to be excercises ;)
Did you realize that they are extremely challenging exercises? Replacing" namespace gtl { ... }" by "namespace boost { namespace polygon { ... } }" is correct and sufficient to make the files compile with gcc compilers. (As you can guess, this got broken when the library was renamed from gtl to boost::polygon.)
The challenging part is to make the examples compile with msvc-9, by introducing the correct workarounds in the code of the library itself. I had hoped that Steven Wantanabe would try to face this challenge, because it looks as if he was the one who helped fix the other msvc issues. So I counted this compile-failure as a test coverage issue of the unit-tests in my review.
You guys are right that the examples got out of date when I changed the gtl namespace to boost::polygon. I'll fix those right away. The other issue is with compile errors in MSVC9 when using custom types vs. library types. It turns out that I broke MSVC9 compatibility when I back ported to MSVC8. You shouldn't need to add typedef int coordinate_type to CPoint, the problem is that it is not applying SFINAE at the right point in the instantiation of the interval concept overloads of functions I'm using from the point concept. To fix this I need to modify the declarations within the library so that MSVC8 and MSVC9 will both work. I all likelyhood I inadvertantly removed a MSVC9 specific workaround that just needs to be reintroduced. I do plan on fixing that issue as soon as possible. Luke
Simonson, Lucanus J wrote:
Thomas Klimpel wrote:
Joachim Faulhaber wrote:
after replacing gtl:: by boost::polygon:: and namespace gtl { ... } by namespace boost { namespace polygon { ... } }
and adding
typedef int coordinate_type;
to struct CPoint
the code finally compiled. Are these examples intended to be excercises ;)
Did you realize that they are extremely challenging exercises? Replacing" namespace gtl { ... }" by "namespace boost { namespace polygon { ... } }" is correct and sufficient to make the files compile with gcc compilers. (As you can guess, this got broken when the library was renamed from gtl to boost::polygon.)
The challenging part is to make the examples compile with msvc-9, by introducing the correct workarounds in the code of the library itself. I had hoped that Steven Wantanabe would try to face this challenge, because it looks as if he was the one who helped fix the other msvc issues. So I counted this compile-failure as a test coverage issue of the unit-tests in my review.
You guys are right that the examples got out of date when I changed the gtl namespace to boost::polygon. I'll fix those right away. The other issue is with compile errors in MSVC9 when using custom types vs. library types. It turns out that I broke MSVC9 compatibility when I back ported to MSVC8. You shouldn't need to add typedef int coordinate_type to CPoint, the problem is that it is not applying SFINAE at the right point in the instantiation of the interval concept overloads of functions I'm using from the point concept. To fix this I need to modify the declarations within the library so that MSVC8 and MSVC9 will both work. I all likelyhood I inadvertantly removed a MSVC9 specific workaround that just needs to be reintroduced. I do plan on fixing that issue as soon as possible.
It turns out that the SFINAE inducing null pointer default argument MSVC8 workaround breaks the build in MSVC9 if the arguments that come before instantiate templates which generate syntax errors. I know how to fix the issue by using the return argument MSVC8 SFINAE workaround, and should have the examples compiling in MSVC9 by the end of the day. Luke
Joachim Faulhaber wrote:
2009/8/31 Thomas Klimpel <Thomas.Klimpel@synopsys.com>:
Joachim Faulhaber wrote:
Are these examples intended to be excercises ;)
Did you realize that they are extremely challenging exercises?
Don't take my remark too seriously. I don't claim this was a big job. Nevertheless I think it is important fix those examples soon because they give a false impression to this exceptional library.
Examples are important, they are read first and compiled first, when people get interested.
The examples and library code required to compile them in MSVC9 are now fixed. I have to review my other usage of the default pointer argument SFINAE guard to ensure that it won't cause syntax errors in MSVC9 with other library functions that weren't exercised in the examples. With luck we should be able to start talking about compiler warnings again and leave discussion of compiler errors behind us. Thanks, Luke
2009/8/31 Simonson, Lucanus J <lucanus.j.simonson@intel.com>:
The examples and library code required to compile them in MSVC9 are now fixed. I have to review my other usage of the default pointer argument SFINAE guard to ensure that it won't cause syntax errors in MSVC9 with other library functions that weren't exercised in the examples. With luck we should be able to start talking about compiler warnings again and leave discussion of compiler errors behind us.
Thanks, Luke
you're faster than lightspeed ;)
participants (3)
-
Joachim Faulhaber -
Simonson, Lucanus J -
Thomas Klimpel