Stewart, Robert wrote:
Simonson, Lucanus J wrote:
Steven Watanabe wrote:
isotropy.hpp:308 What does y_c_edist mean, and why are you including a constant in the gtl_and for euclidean_distance?
This is a compiler workaround for MSVC8. There are a large number of them, unfortuantely. It is named with a mangling scheme related to the concept and function name that uses it. MSVC8 has two different code paths for instantiating templates and applying SFINAE. The one where it recognizes that it has seen a subtemplate before is incorrect and I used these constant types that are unique to each function to force MSVC8 to SFINAE correctly. I could perhaps put a
//MSVC8 workaround
on each one so that it doesn't cause too much confusion.
(Caveat: I'm only responding to what I read here: I haven't looked at the code in question. I may be way off the mark.)
How about introducing a macro taking a constant argument, that evaluates to the supplied constant, plus required punctuation, for MSVC8 and to nothing for other compilers? That would make the code self documenting and eliminate any #ifdef's where used.
BOOST_POLYGON_MSVC8_SFINAE_WORKAROUND?
The constant needs to be a unique type in each instance that the workaround is used. Also, there are no ifdefs used for this workaround because the code is legal in all compilers. Luke