Simonson, Lucanus J wrote:
It looks to me like I should just eliminate the #else clause and keep only your SFINAE-less compile time logic since it is feature complete and supported by more compilers.
You could eliminate the #else clause, but I don't think that you should. After all, it is a workaround, and it is much more difficult to read than the original version, at least for me.
Also this eliminates the macro (and the need to document it.)
Oh, I guess that a compiler that already chokes when just including polygon.hpp will need much more code changes and workarounds than just this single traits definition. I tried this and downloaded a free special edition of a Freescale CodeWarrior compiler. It turns out that to even compile a file that only includes polygon.hpp without actually using it, the attached patch to scan_arbitrary.hpp is required. I didn't even try actually compiling one of the examples, but I guess that much more work would be required to get these compile.
Is there a reason you kept the SFINAE based code and used a macro to switch between the two other than to test your compile time logic against the original?
I guess that more workarounds will be required to port the SFINAE heavy Boost.Polygon code to a compiler with BOOST_VERY_LITTLE_SFINAE defined.
As a side note, the latest revision of Boost.Polygon doesn't pass all regression tests on MSVC-9.0 ...
fixed
Very good, I can confirm that the regression tests on MSVC-9.0 pass again. Regards, Thomas