Re: [boost] [Polygon] review - isotropy.hpp

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