Subject: Re: [boost] [Polygon] review - isotropy.hpp
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-08-31 10:59:45
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