Re: [boost] MSVC9 SFINAE quirks?

Subject: Re: [boost] MSVC9 SFINAE quirks?
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2009-01-12 17:34:18

AMDG

Simonson, Lucanus J wrote:
>> 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.
>   

The difference is that the for literal templates, the compiler does not
even try to instantiate it.  For SFINAE, the compiler has to instantiate it.
Basically, the compiler only instantiates what it needs to.

template<class T>
typename boost::enable_if<
    boost::mpl::and_<
        a_metafunction<T>,  // not instantiated yet
        another_metafunction<T>  // not instantiated yet
    >,  // not instantiated yet
    some_template<T> // not instantiated yet
 >::type // Now we get some template instantiation
f(T);

enable_if must be instantiated to get at the ::type.
enable_if in turn forces instantiation of and_ which forces
instantiation of one or both of the metafunctions.

In Christ,
Steven Watanabe