Return-Path: 
 <dev-return-7840-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org>
Delivered-To: apmail-stdcxx-dev-archive@www.apache.org
Received: (qmail 55611 invoked from network); 12 Jun 2008 22:02:49 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 12 Jun 2008 22:02:49 -0000
Received: (qmail 52992 invoked by uid 500); 12 Jun 2008 22:02:51 -0000
Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org
Received: (qmail 52978 invoked by uid 500); 12 Jun 2008 22:02:51 -0000
Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@stdcxx.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@stdcxx.apache.org>
List-Post: <mailto:dev@stdcxx.apache.org>
List-Id: <dev.stdcxx.apache.org>
Reply-To: dev@stdcxx.apache.org
Delivered-To: mailing list dev@stdcxx.apache.org
Received: (qmail 52965 invoked by uid 99); 12 Jun 2008 22:02:51 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Jun 2008 15:02:51 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [208.30.140.160] (HELO moroha.roguewave.com) (208.30.140.160)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Jun 2008 22:02:02 +0000
Received: from exchmail01.Blue.Roguewave.Com (exchmail01.blue.roguewave.com
 [10.22.129.22])
	by moroha.roguewave.com (8.13.6/8.13.6) with ESMTP id m5CM0ID3015818
	for <dev@stdcxx.apache.org>; Thu, 12 Jun 2008 22:00:18 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: static_assert config check
Date: Thu, 12 Jun 2008 16:00:04 -0600
Message-ID: 
 <CFFDD219128FD94FB4F92B99F52D0A499AA8A4@exchmail01.Blue.Roguewave.Com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: static_assert config check
Thread-Index: AcjMggPS7dVQadTSSMyajg2G8DWavAAUfypQ
References: 
 <CFFDD219128FD94FB4F92B99F52D0A49010A383B@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA897@exchmail01.Blue.Roguewave.Com>
 <48510C42.2030506@roguewave.com>
From: "Travis Vitek" <Travis.Vitek@roguewave.com>
To: <dev@stdcxx.apache.org>
X-Virus-Checked: Checked by ClamAV on apache.org

=20

Martin Sebor wrote:
>Travis Vitek wrote:
>>> Eric Lemings wrote:
>>>
>>>
>>> How's this for a suitable configuration check for static_assert?
>>>
>>> 	// compile-only test
>>>
>>> 	static_assert (sizeof (char) =3D=3D 1, "impossible");
>>>
>>> 	template <int I> struct S {
>>> 	    static_assert (I >=3D 0, "template parameter I must be
>>> non-negative");
>>> 	};
>>>
>>=20
>> I've written an errily similar test already (pasted below)
>>=20
>> I think you should probably instantiate S somewhere and it might be a
>> good idea put a line break before 'struct' so that your code=20
>> conforms to our 'coding standards'.=20
>[...]
>
>It's probably overkill, but just as an FYI, to verify this works
>both ways the test would need to be negative, i.e., named NO_XXX,
>and write #define _RWSTD_NO_XXX to stdout if the negative assert
>failed to fire.

So how exactly is the test supposed to write anything to stdout if it
doesn't compile? If the expression of the static_assert is false, the
program is ill-formed and the compiler is to emit a diagnostic.

I'm looking at this and if I name the test NO_STATIC_ASSERT.cpp and it
fails to compile, the macro _RWSTD_NO_STATIC_ASSERT wll be defined, so
using the NO_ prefix doesn't really buy me anything. I don't think it
would be right to make it so that if a NO_XXX test fails to compile the
macro _RWSTD_NO_XXX will not be defined.

The only way I see to ensure that static_assert is actually working both
ways is to write two tests, one testing for passing conditions
[STATIC_ASSERT_PASS.cpp], and the other testing for failing conditions
[STATIC_ASSERT_FAIL.cpp]. Then we would define _RWSTD_NO_STATIC_ASSERT
like so...

  #if    !defined (_RWSTD_NO_STATIC_ASSERT_PASS)
      ||  defined (_RWSTD_NO_STATIC_ASSERT_FAIL)
  // STATIC_ASSERT_PASS.cpp failed to compile
  // STATIC_ASSERT_FAIL.cpp compiled without error
  #  define _RWSTD_NO_STATIC_ASSERT
  #endif

Is that overkill?

>Martin
>
>> template <int _N>
>> struct S
>> {
>>     static_assert (0 < _N, "fail");
>> };
>>=20
>> template <int _N>
>> void f ()
>> {
>>     static_assert (0 < _N, "fail");
>> }
>>=20
>> int main ()
>> {
>>     S<1> s1;
>>     f<1>();
>>     static_assert (1, "pass");
>>=20
>>     return 0;
>> }
>
>