Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: type_traits progress
Date: Mon, 2 Jun 2008 14:38:12 -0600
Message-ID: 
 <CFFDD219128FD94FB4F92B99F52D0A49010A37FD@exchmail01.Blue.Roguewave.Com>
Thread-Topic: type_traits progress
Thread-Index: AcjE7X1hoRL2JTbrRAa1YDn5VH8b+QAAq/kA
References: 
 <CFFDD219128FD94FB4F92B99F52D0A499AA862@exchmail01.Blue.Roguewave.Com>
 <483B79A1.4070808@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA864@exchmail01.Blue.Roguewave.Com>
 <483C67BA.6070209@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA86C@exchmail01.Blue.Roguewave.Com>
 <48401E00.2090709@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA86D@exchmail01.Blue.Roguewave.Com>
 <48409378.3010407@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA871@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A37F5@exchmail01.Blue.Roguewave.Com>
 <48445493.4080400@roguewave.com>
From: "Eric Lemings" <Eric.Lemings@roguewave.com>
To: <dev@stdcxx.apache.org>

=20

> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]=20
> Sent: Monday, June 02, 2008 2:14 PM
> To: dev@stdcxx.apache.org
> Subject: Re: type_traits progress
>=20
> Eric Lemings wrote:
> > =20
> >=20
> >> -----Original Message-----
> >> From: Travis Vitek [mailto:Travis.Vitek@roguewave.com]=20
> >> Sent: Friday, May 30, 2008 6:28 PM
> >> To: dev@stdcxx.apache.org
> >> Subject: RE: type_traits progress
> >>
> >> =20
> >>
> >> 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=20
> >>>> 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=20
> >> 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=20
> thing that bugs
> >>> me about it is...
> >>>
> >>>> template <class T, T v>
> >>>> struct __rw_integral_constant
> >>>> {
> >>>>   static const T value =3D v;
> >>>>   typedef T value_type;
> >>>>   typedef integral_constant<T,v> type;
> >>> ...this backward dependency on integral_constant, but I=20
> don't see how
> >>> to break it without template typedefs. I don't think there's=20
> >> a compiler
> >>> out there that supports them yet.
> >> Actually, this was originally a typo on my part, but I do see=20
> >> 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.
> >=20
> > Yeah it looks like a typo to me too.  Should it be:
> >=20
> > 	typedef __rw_integral_constant<T,v> type;
> >=20
> > In all cases I've seen, `type' refers to type of self for identity
> > properties.  This typedef would not hold up the identity property.
>=20
> IIUC, for every specialization X of integral_constant, this
> must hold:
>=20
>    is_same<X, typename X::type>::value =3D=3D true
>=20
> With integral_constant derived from __rw_integral_constant
> the condition would fail.

Not if it defined its own `type'.

	template <class T, T v>
	struct integral_constant: __rw_integral_constant<T, v>
	{
	  typedef integral_constant<T, v> type;
	};

That's the way I usually see it done.

Brad.