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/20.meta.help.cpp,
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.
Martin
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
