stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: type_traits progress
Date Wed, 28 May 2008 15:21:42 GMT
Travis Vitek wrote:
> Martin Sebor wrote:
>> One comment on the design of the tests: template instantiation
>> is very expensive both in terms of compiler cycles and in terms
>> of disk space taken up by the generated object code. We need to
>> avoid instantiating more than the bare minimum of code. So for
>> example, in tests/utilities/,
>> test_integral_constant() would ideally be an ordinary function
>> with the expected and tested values being passed in by the macro.
>> Also, if there's a way to avoid using function templates (such
>> as test_is_same_type) and use class templates instead it should
>> save us some cycles (especially with optimization) and disk
>> space.
> This is an excellent point, and a relatively easy fix to apply in most
> cases.
> A quick question on this subject. In many cases it is convenient to use
> traits in testing other traits. As an example I would like to use
> std::is_same<T,U>::value when testing traits like std::is_const. If I
> test is_same using hard coded values, is it acceptable to use is_same
> when testing other traits like add_const? If I don't use std::is_same,
> then I would need to write something similar to is_same [either a class
> or function template] to give me the answer. What does everyone think?

I normally try to avoid relying on parts of a tested product
to exercise others, but in this case it does seem like you
could end up duplicating much of the tested functionality
in the tests themselves. It's a judgment call.


>> As an aside, tests don't need to use the _STD macro. The test
>> config header testdefs.h does the necessary magic to let us use
>> the name std directly even when _RWSTD_NO_NAMESPACE is #defined.
> Hah, necessary magic equals #define. Yeah, I noticed this. I'll update
> my tests.
>> Martin

View raw message