----- Original Message ----- From: "David B. Held" <[EMAIL PROTECTED]>
> "Jon Kalb" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > icrosoft.com... > > [...] > > Vandevoorde and Josuttis call it SFINAE, "substitution failute is not an > > error." > > Ah, I've heard of this, but didn't realize what it was all about. > > > In "C++ Templates: The Complete Guide" (Recommended), they give > > this example on pages 106-107: > > > > typedef char RT1; > > typedef struct {char a[2];} RT2; > > template<typename T> RT1 test(typename T::X const*); > > template<typename T> RT2 test(...); > > > > #define type_has_member_type_X(T) \ > > (sizeof(test<T>(0) == 1) > > This is cool. What compilers are known to support it? Comeau C++ certainly supports it (what a surprise...). BTW, this is nothing new. It was discovered a while back based on an "is_enum" implementation, which was converted to an "is_class" implementation, which, finally, was converted to a "has_member_..." implementation. (I think by Rani Sharoni, but I'm not sure.) The bad part about it is that there is no way, given the nature of the solution, to parametize the member name. Also, SFINAE, according to the standard does not apply to expression errors, and is very unclear about what happens, for example in the code above, if "X" is a template instead of a regular type. I talked to Daveed Vandevoorde about this issue this past week. Supposedly, the SFINAE principle used to be very broad, but compilers were having difficulty implementing it "robustly," so they (as in core-3) dumbed it down to only include the "list of ways that deduction/substitution can fail" in 14.8.2. This list is, in effect, a list of negatives--which IMO is a bad idea. Apparently, they've added things to this list in each of the last three core-3 meetings (or whatever they are). Personally, I believe the SFINAE principle should be significantly broader. The original argument about the "difficulty" of a robust implementation is pretty bogus considering that most compilers won't handle just the invalid type-creation attempts listed in 14.8.2 anyway. Also, the line between "invalid type" and "invalid expression" is significantly blurred because of the sizeof and typeid operators (not to mention "invalid templates"). Consider again how brittle the above might be: template<class T> char test(typename T::X const*); template<class T> char (& test(...))[2]; #define has_member_type_X(T) \ (sizeof( test<T>(0) ) == 1) struct Y { template<class> struct X { }; }; has_member_type_X(Y) // ? Paul Mensonides _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
