Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.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: tests/utilities/20.meta.help.cpp
Date: Mon, 23 Jun 2008 16:03:55 -0600
Message-ID: 
 <CFFDD219128FD94FB4F92B99F52D0A499AA8C6@exchmail01.Blue.Roguewave.Com>
Thread-Topic: tests/utilities/20.meta.help.cpp
Thread-Index: AcjVPeBrjkN2/MDcRD6b9cafTqCsrwAOXAig
References: 
 <CFFDD219128FD94FB4F92B99F52D0A4901DB05D7@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA8BF@exchmail01.Blue.Roguewave.Com>
 <485FB332.3070906@roguewave.com>
From: "Travis Vitek" <Travis.Vitek@roguewave.com>
To: <dev@stdcxx.apache.org>

=20

Martin Sebor wrote:
>
>Travis Vitek wrote:
>> =20
>> Eric Lemings wrote:
>>>
>>> Just a brief side note.  I was just reviewing this test and=20
>>> noticed that
>>> pointers are not tested though they are valid scalar types=20
>suitable for
>>> use as integral_constant parameters.  I think references=20
>may be valid
>>> parameters also.
>>>
>>=20
>> I'm not sure.
>>=20
>> The first thing that jumps to mind is that a pointer is not of
>> 'integral' type. An enumeration isn't really an integral type either,
>> but they are implicitly convertible to one. Pointers aren't=20
>convertible
>> to integral type without a cast.
>>=20
>> According to temp.arg.nontype, a non-type, non-template template
>> parameter must be one of
>>=20
>>   -- an integral constant expression
>>   -- the name of a non-type template-parameter
>>   -- the address of an object or function with external linkage...
>>   -- a constant expression that evaluates to a null pointer value
>>   -- a constant expression that evaluates to a null member=20
>pointer value
>>   -- a pointer to member
>>=20
>> So, yes, it is legal to use a pointer as a non-type template=20
>parameter.
>>=20
>> The issue I have is that the integral_constant<T,V> is supposed to
>> define an integral constant of type T with value V. Section=20
>expr.const
>> says that a constant expression is an integral constant=20
>expression if it
>> is of integral or enumeration type. An integral constant=20
>expression can
>> be used as an array bound, a case expression, a bit field length,
>> enumeration initializer, static member initializer and as integral or
>> enumeration non-type template arguments.
>>=20
>> I'm pretty sure you can't use a pointer value as an array bound, case
>> expression, bit field length or enumeration initializer, so=20
>they aren't
>> really integral constants.
>>=20
>> So I am sure you can instantiate std::integral_constant<void
>> (class_t::*)(), &class::method>, but I'm not sure if it=20
>something that
>> should be tested.
>
>If there's an implementation technique that would make the
>instantiation ill-formed then I think it should be tested.

According to class.mem (p4) and class.static.data (p4) you aren't
allowed to initialize static members using a constant-initializer (i.e.
in the member declaration) if they are not of const integral or const
enumeration type. So the above instantiation on member pointer should be
prevented by the compiler. A quick test with msvc-8.0 and gcc-4.3 show
that this is the case.

The following would be legal, but I'm already testing integral constants
for all integral types and an enum type, so I think I'm covered.

>
>More important, though, the standard should specify the
>requirements on the template arguments. If there are no
>such requirements for something as fundamental as
>integral_const, either in the latest working draft or
>in one of the concepts papers (such as N2622), we should
>at least bring it up on the list and/or open an issue to
>have the spec clarified.

The standard does specify the requirements of the template arguments,
but only through association (to be an integral constant member, it has
to be a const static that is initialized with a constant-initializer,
and a constant initializer only works for enum and integral types). Is
this significant enough to warrant bringing up an issue?

Travis