Testing <type_traits>
Jonathan Wakely
jwakely@redhat.com
Fri Oct 7 17:24:00 GMT 2016
On 07/10/16 10:28 -0600, Martin Sebor wrote:
>On 10/07/2016 05:47 AM, Jonathan Wakely wrote:
>>Most type traits have a requirements/typedefs.cc test like this:
>>
>>#include <type_traits>
>>
>>void test01()
>>{
>> // Check for required typedefs
>> typedef std::has_virtual_destructor<int> test_type;
>> typedef test_type::value_type value_type;
>> typedef test_type::type type;
>> typedef test_type::type::value_type type_value_type;
>> typedef test_type::type::type type_type;
>>}
>>
>>Wouldn't it be better to do something like this instead?
>>
>> typedef std::has_virtual_destructor<int> test_type;
>> static_assert( std::is_same<test_type::value_type, bool>::value, "" );
>> typedef integral_constant<bool, test_type()()> bool_type;
>> static_assert( std::is_same<test_type::type, bool_type>::value, "");
>>
>>We should be checking that ::type is bool_constant, and if we do that
>>then we don't need to bother testing type::type and type::value_type.
>
>I agree that the existing test you showed seems quite weak
>and ineffective and that the suggested test would be better.
>
>My only (general) suggestion in developing tests for library
>features it to try to avoid relying on other library features
>and instead code them either in terms of lower-level (core)
>constructs or in terms of independently developed testsuite
>helpers.
>
>For example, if std::foo is wrong or breaks, it's helpful if
>it's revealed by a test for std::foo failing without also
>causing tests for std::bar and std::baz to fail. I realize
>that this may be overly general or ambitious for some library
>components and may not even be a good approach std::foo is
>specified in terms of std::bar and std::baz, but in general
>it's my experience that striving for this goal makes debugging
>regressions introduced during development much easier.
>
>Translating this to the first static_assert above might lead
>to something like this:
>
> const bool *p = (test_type::value_type*)0;
Good point. When testing other headers I sometimes define my own
version of is_same so I'm not relying on std::is_same (even though
nearly every header in the library includes <type_traits> indirectly
anyway).
As this test was specifically for something in <type_traits> I figured
using std::is_same would be OK, especially as std::is_same is so
simple it's hard to imagine it would go wrong.
More information about the Libstdc++
mailing list