Re: [boost] MSVC9 SFINAE quirks?

Subject: Re: [boost] MSVC9 SFINAE quirks?
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-01-12 17:07:57

>>>  template <typename geometry_type_1, typename geometry_type_2>
>>>  typename boost::enable_if<
>>>      boost::mpl::and_<is_any_polygon_set_type<geometry_type_1>,
>>>                       is_any_polygon_set_type<geometry_type_2>,
>>>                       is_either_polygon_set_type<geometry_type_1, 
>>> geometry_type_2>
>>>      >,
>>>      polygon_set_view<geometry_type_1, geometry_type_2, 3>
>>>  >::type
>>>  operator-(const geometry_type_1& lvalue, const geometry_type_2& rvalue) {
>>>    return polygon_set_view<geometry_type_1, geometry_type_2, 3>
>>>      (lvalue, rvalue);
>>>  }
>>>     
>
>> This won't work.  In order to instantiate enable_if the compiler must >>instantiate both of its arguments.  That means the compiler will try to >>instantiate polygon_set_view<> for every time the generic operator - in >>the stl is used for iterator arithmetic.  Any error encountered trying to >>instantiate polygon_set_view will cause a syntax error and failed >>compilation even though the and_ evaluates to false.
>   

>Not true.  Simply naming
>polygon_set_view<geometry_type_1, geometry_type_2, 3>
>doesn't force it to be instantiated.  If you're getting an error from
>this, there must be some other reason.

You are right, there must be some other reason.  I changed requires_1 to be identically boost::enable_if and it worked the way you said it would.  There must be some non-intuitive difference between the way MSVC parses literal constant templates vs. templates on type for SFINAE purposes.  My assumption was that SFINAE situations should parse the same whether the template where substitution fails is a template on a literal constant or on a type, which seems to be the case in gcc.

Thank you for helping me with this,
Luke