Re: [boost] Re: [MPL] Making Generators
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> > MPL's implementation ("boost/mpl/aux_/has_xxx.hpp") is
>> > known to work on Comeau, Intel (all versions), MSVC (all versions),
>> > Metroweks 8.3/8.2 and GCC 3.2. There is no known way to make it
>> > work on Borland. You can test it against any other compiler by
>> > trying out "boost/libs/mpl/test/aux_/has_xxx.cpp" test case.
>>
>> It also works with GCC 2.95.2 with some restrictions. I don't remember
>> what they are offhand. Something like that the type must be a class?
>> ... that doesn't sound quite right because we could work around it
>> with an is_class pre-test.
>
> I wouldn't call it "works": it returns 'true' if the member exists,
> otherwise it fails with a compilation error (whether the tested type is a
> class or not). Or it would fail if we didn't #ifdef'ed it to always return
> 'false'.
My vague memory is that it works as long as the member is not a
reference type... or something.
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [MPL] Making Generators
David Abrahams wrote:
> > MPL's implementation ("boost/mpl/aux_/has_xxx.hpp") is
> > known to work on Comeau, Intel (all versions), MSVC (all versions),
> > Metroweks 8.3/8.2 and GCC 3.2. There is no known way to make it
> > work on Borland. You can test it against any other compiler by
> > trying out "boost/libs/mpl/test/aux_/has_xxx.cpp" test case.
>
> It also works with GCC 2.95.2 with some restrictions. I don't remember
> what they are offhand. Something like that the type must be a class?
> ... that doesn't sound quite right because we could work around it
> with an is_class pre-test.
I wouldn't call it "works": it returns 'true' if the member exists,
otherwise it fails with a compilation error (whether the tested type is a
class or not). Or it would fail if we didn't #ifdef'ed it to always return
'false'.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [MPL] Making Generators
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
> David B. Held wrote:
>> > 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 RT1 test(typename T::X const*);
>> > template RT2 test(...);
>> >
>> > #define type_has_member_type_X(T) \
>> > (sizeof(test(0) == 1)
>>
>> This is cool. What compilers are known to support it?
>
> MPL's implementation ("boost/mpl/aux_/has_xxx.hpp") is known to work on
> Comeau, Intel (all versions), MSVC (all versions), Metroweks 8.3/8.2 and GCC
> 3.2. There is no known way to make it work on Borland. You can test it
> against any other compiler by trying out
> "boost/libs/mpl/test/aux_/has_xxx.cpp" test case.
It also works with GCC 2.95.2 with some restrictions. I don't remember
what they are offhand. Something like that the type must be a class?
... that doesn't sound quite right because we could work around it
with an is_class pre-test.
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [MPL] Making Generators
David B. Held wrote:
> > 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 RT1 test(typename T::X const*);
> > template RT2 test(...);
> >
> > #define type_has_member_type_X(T) \
> > (sizeof(test(0) == 1)
>
> This is cool. What compilers are known to support it?
MPL's implementation ("boost/mpl/aux_/has_xxx.hpp") is known to work on
Comeau, Intel (all versions), MSVC (all versions), Metroweks 8.3/8.2 and GCC
3.2. There is no known way to make it work on Borland. You can test it
against any other compiler by trying out
"boost/libs/mpl/test/aux_/has_xxx.cpp" test case.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [MPL] Making Generators
- 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 RT1 test(typename T::X const*);
> > template RT2 test(...);
> >
> > #define type_has_member_type_X(T) \
> > (sizeof(test(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 char test(typename T::X const*);
template char (& test(...))[2];
#define has_member_type_X(T) \
(sizeof( test(0) ) == 1)
struct Y {
template struct X { };
};
has_member_type_X(Y) // ?
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [MPL] Making Generators
> -Original Message-
> From: David B. Held [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 05, 2002 10:56 AM
> To: [EMAIL PROTECTED]
> Subject: [boost] Re: [MPL] Making Generators
>
>
> "David Abrahams" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > [...]
> > I don't know... well, it could detect whether there was a ::type
> > member, [...]
>
> Really??? Is it possible to detect the presence of a typedef
> without generating an error? How do you do this? I think
> this is a very useful feature!
>
> Dave
Vandevoorde and Josuttis call it SFINAE, "substitution failute is not an
error."
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 RT1 test(typename T::X const*);
template RT2 test(...);
#define type_has_member_type_X(T) \
(sizeof(test(0) == 1)
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [MPL] Making Generators
"David B. Held" <[EMAIL PROTECTED]> writes: > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> [...] >> I don't know... well, it could detect whether there was a ::type >> member, >> [...] > > Really??? Is it possible to detect the presence of a typedef without > generating an error? How do you do this? I think this is a very useful > feature! On many compilers, yes. See mpl/aux_/has_xxx.hpp -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
