oh ok...I thought over what you wrote for like 2 min and now I think I get it. Thought those kind of failures (instantiation faliures) let SFINAE kick in too. But now I am comprehending it as follows:
<1> Check if the instantiation would be correct - as if for example you were defining a variable
of that type independently somewhere then that should be doable.
<2> If that is fine then go ahead and try to access the stuff of the instantiated type which you would substitute there. If that fails then it's SFINAE candidate. However if <1> fails then it's like a hard error.
Is that fine?
Just one more quick question on the same:
Going on those lines if you have
1 2
|
template<typename T>
struct A<T, typename One<Two<typename T::type>::value>::type> { };
|
<3> if
typename T::type
is valid,
Two<typename T::type>::value
is valid,
One<.....>
is valid but
typename One<....>::type
is
invalid, then SFINAE would kick in and the specialization would be discarded.
But would all the prior instantiations cause the compiler to actually generate code for types T
, Two<...>
and One<...>
?
<4> if all of them are valid and specialization is chosen
will the code for those be generated in the object code?
I mean is it required by the standard/logic (Not talking about optimizer involvement etc)?
note- Consider I'm using them only for SFINAE, not using them (struct A is empty above}.