stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: structure of tuple tests ([Fwd: Re: svn commit: r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h include/tuple tests/utilities/20.tuple.cnstr.cpp tests/utilities/20.tuple.creation.cpp tests/utilities/20.tuple.h tests/utilities/20.tuple.helpers
Date Thu, 17 Jul 2008 05:11:20 GMT
Eric Lemings wrote:
>  
> 
>> -----Original Message-----
>> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
>> Sent: Friday, July 11, 2008 1:06 PM
>> To: dev@stdcxx.apache.org
>> Subject: Re: structure of tuple tests ([Fwd: Re: svn commit: 
>> r675044 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h 
>> include/tuple tests/utilities/20.tuple.cnstr.cpp 
>> tests/utilities/20.tuple.creation.cpp 
>> tests/utilities/20.tuple.h tests/utilities/20.tuple.helpers
>>
> ...
>> You might want to consider extending the UserClass class defined
>> in tests/include/rw_value.h, or at least borrowing code or ideas
>> from it.
> 
> I generalized the overall test pattern for tuples with the latest
> revision 677458.  It might not be exactly what you're after but I
> think it's much closer than the previous version.  For instance, I
> lot of the tests could be wrapped in TEST() function macros.
> 
> Have a look if you find time.

Okay, I looked :) Just briefly, but I do have a few high-level
comments and suggestions for you.

First, let's avoid using one library component to test another.
Especially avoid using ostream except in tests exercising I/O
(those should be separate from all others). We shouldn't be
#including <ostream> or <string> in 20.tuple.h. Also avoid
using std::rand() and, ideally, any randomization at all. It
makes it hard to reliably reproduce the same test results.
For <type_traits>, if all tuple needs is decay, it would be
nice if we could come up with a way to do without it. In
20.tuple.cnstr.cpp you might also be able to get rid of
<cstring> by using rw_strncmp(). You should also be able
to use rw_equal() instead of defining a special helper (if
rw_equal() doesn't do something we need to do in the tuple
tests maybe we could extend it?)

Another point: most people expect headers to be #included at
the top of a file. It's surprising to see them included in
the middle, and it can have unexpected effects in template
code. Please move all #include directives to the top of the
20.tuple.cnstr.cpp test.

Third, I would rather strongly recommend removing the global
tuple typedefs from the common header and defining them in
each test function as necessary. AFAICS, they don't save us
anything (they're all onle-liners), and it's far from clear
from their names what each of them represents. Having their
exact types spelled out at the point of their use will make
the tests more readable, and much easier to change. The
current setup suggests that to add a single test case for
a new tuple we will have to edit the 20.tuple.h header shared
across all tests, exposing all of them to the fallout from
our edits.

Also, it's generally a good idea to write headers in a way
that lets them be #included in multiple translation units of
the same program. That means avoiding data definitions (except
for those with internal linkage). I realize that 20.tuple.h
isn't meant to be #included by multiple TUs, but that might
change, especially if we decide to move the header into
tests/include like all other common headers, and compile
its contents into the test driver.

So that wasn't as brief as I had hoped but hopefully it'll
help us converge on an optimal design.

Martin

Mime
View raw message