Eric Lemings wrote:
-----Original Message-----
From: Travis Vitek [mailto:[EMAIL PROTECTED]
Sent: Friday, May 30, 2008 6:28 PM
To: dev@stdcxx.apache.org
Subject: RE: type_traits progress
Martin Sebor wrote:
Travis Vitek wrote:
[...]
Right. That could be another wrinkle. Our traits won't
work with generic code that takes integral_constant<T, V>
by reference.
I don't really see the motivation, but it is obvious that
the committee thought it was important for the standard
traits to do so, so we should probably follow suit in our
internal implementation.
Can you think of a reason why this 'feature' would be important?
If we did decide to do this then we would probably want
our own write
__rw_integral_constant and use that internally to avoid namespace
pollution? Then I'd assume we'd want something like the following
example for is_const...
Yes, I think this is close to what we want. The only thing that bugs
me about it is...
template <class T, T v>
struct __rw_integral_constant
{
static const T value = v;
typedef T value_type;
typedef integral_constant<T,v> type;
...this backward dependency on integral_constant, but I don't see how
to break it without template typedefs. I don't think there's
a compiler
out there that supports them yet.
Actually, this was originally a typo on my part, but I do see
where this
is going. I haven't read about template typedefs, but it seems that
there would be a serious problem caused by the cyclic dependency.
Yeah it looks like a typo to me too. Should it be:
typedef __rw_integral_constant<T,v> type;
In all cases I've seen, `type' refers to type of self for identity
properties. This typedef would not hold up the identity property.
IIUC, for every specialization X of integral_constant, this
must hold:
is_same<X, typename X::type>::value == true
With integral_constant derived from __rw_integral_constant
the condition would fail.
Martin
