> -----Original Message-----
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Thursday, June 26, 2008 12:32 PM
> To: [email protected]
> Subject: Re: __rw_and (Was RE: Some internal aliases for
> __rw_integral_constant?)
>
...
>
> I can't say I understand this use case. What's S meant to represent?
That was just a contrived example; not intended to be realistic.
> It looks like some sort of a type trait. If so, why isn't plain &&
> sufficient?
Portability. As I said, some compilers have problems evaluating certain
expressions at compile-time without metafunction wrappers.
>
> template <class T, int I>
> struct S:
> __rw_conditional<__rw_is_class<T>::value && 0 != I, T, ???>
> { };
>
> (Or enable_if instead of conditional, depending on what you want
> to do with S).
>
> >
> > template <class... T> struct O {
> > template <class... U> struct I
> > : __rw_and<std::is_convertible<T, U>::value...> {}; //
> > variable arguments
>
> Same here.
Try writing that without __rw_and. :) I did. Well, tried at least.
It is NOT easy. In fact, this was the main reason I wrote the __rw_and
class template to begin with.
>
> > };
> >
> > The other reason is portability. Case in point. Travis
> recently ran
> > into a problem where the compiler rejected a simple
> constant expression
> > like `sizeof (T) < sizeof (U)' but worked with the metafunction
> > equivalent of `__rw_less_than<sizeof (T), sizeof (U)>::value'.
>
> This sounds like an argument for __rw_less_than, not for __rw_and.
>
> Btw., I'm not opposed to __rw_and in principle. I just want to see
> some of its uses and the rationale for it (in case there's a better
> or simpler way of doing the same thing).
The "is_convertible" use case is the best rationale for it that I can
think of. Such metafunctions essentially allow type traits to be used
on type _lists_ rather than individual types; e.g.,
template <class... Types>
struct all_integral_types
: __rw_and<std::is_integral<Types>::value...> {};
I dunno 'bout you, but I think that's pretty darn cool. :) Oh, and a
lot simpler than the alternative. (I'm not convinced there even is
one.)
Brad.
