stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: static_assert config check
Date Fri, 13 Jun 2008 07:07:25 GMT
Eric Lemings wrote:
>  
> 
>> -----Original Message-----
>> From: Travis Vitek [mailto:Travis.Vitek@roguewave.com] 
>> Sent: Thursday, June 12, 2008 4:00 PM
>> To: dev@stdcxx.apache.org
>> Subject: RE: static_assert config check
>>
>>  
>>
>> 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) == 1, "impossible");
>>>>>
>>>>> 	template <int I> struct S {
>>>>> 	    static_assert (I >= 0, "template parameter I must be
>>>>> non-negative");
>>>>> 	};
>>>>>
>>>> I've written an errily similar test already (pasted below)
>>>>
>>>> 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 
>>>> conforms to our 'coding standards'. 
>>> [...]
>>>
>>> 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?
> 
> Or...you could run the negative test _first_ and if that fails (i.e.
> does not fire as assertion), run the positive test which will produce
> _RWSTD_NO_STATIC_ASSERT only if one or both tests failed.

Something like that. I was mainly aiming to point out that
we have both positive and negative tests. The static_assert
test clearly wasn't a good example because, as Travis noted,
it would need to be split up into two.

Martin

Mime
View raw message