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 15:53:36 GMT
Eric Lemings wrote:
>  
> 
[...]
>> Also avoid
>> using std::rand() and, ideally, any randomization at all. It
>> makes it hard to reliably reproduce the same test results.
> 
> Not in this case.

All the more reason not to use the function.

> 
>> 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.
> 
> Yeah I could add FMT_SPEC() for each combination of cv-qualifier
> and reference types for all types already specified.  I'd rather
> not though and just rely on decay since that's what its meant
> to do.

It's important to avoid relying on one library component
to test another. It's also important to keep the amount
of code included in every test to minimum (to make it
easy to reduce problems to small test cases). AFAICS,
decay is being used here as an implementation detail of
the tuple formatting framework. If there is a way to do
without it (even if it means reimplementing all of trait
in the test), it's preferable to pulling in all of
<type_traits>.

> 
[...]
Eric Lemings wrote:
 >
 >
 >> -----Original Message-----
 >> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
 >> Sent: Wednesday, July 16, 2008 11:15 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
 >>
 >> Btw., here's a prototype of a utility for pretty printing of
 >> tuple types. It might come in handy as a generic implementation
 >> of type_name() for tuples, as a replacement for the handful of
 >> hardwired tuple types we have there.
 >>
 >>
 >> #include <cstring>
 >> #include <tuple>
 >>
 >> template <class T> const char* type_name () { return "???"; }
 >
 > Should be left undefined so that you get a compile error and can
 > add the unreferenced type_name() specialization as appropriate.
 >
 > Also, I'd prefer a compile-time facility for converting types to
 > strings.  There's really no need for using a function, is there?

As I mentioned, it's just a prototype. I'm quite certain
it can (and should) be improved upon. That said, I don't
know of a generic way to concatenate strings at compile
time. If you can figure out how, more power to you!

Martin

Mime
View raw message