Thomas Klimpel wrote:
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.
Well, yes, it did take me a minute of looking at your code to figure out what it was doing. I was actually pretty impressed with the creativity of the template metaprogramming to select which type to inherit from to get all versions of polygon_traits to instantiate from a single definition. The original is sufficiently hard to read that only template meta-programming experts will have a chance. The users already have to rely on documentation and code examples to specialize polygon_traits.
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.
Yikes! I took a look at your patch to scan_arbitrary.hpp. If the CodeWarrior compiler can't find the functions in the templated base class from the context of a derived class then I'll have to qualify a huge number of function calls in several files. I use templated structs as proxy for templated namespace and derive from them to avoid having to fully qualify function calls. This pretty much makes that moot and I might as well not derive at all and just fully qualify everything. We should find out from Kef if he was successfully able to compile and use the algorithms with his variant of CodeWarrior.
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.
Is BOOST_VERY_LITTLE_SFINAE a real boost macro, or just a joke Dave made last time CodeWarrior was discussed?
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.
I have also performed pseudo-exhaustive testing on large scale randomly generated inputs. The library is currently passing these tests and running faster with GMP to provide 100% robustness than it did without GMP at the time it was reviewed. Anyone using the library currently who isn't using GMP due to performance concerns should update now, because the code currently checked in to the sandbox is well tested. Thanks, Luke