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

[Martin Sebor]

Eric Lemings wrote:

>  
> Question.  Given a type T, how do I determine the format specifier for
> outputing values of T?  Would I need to write something like this?
>
> template <class T>
> const char* fmtspec ();
>
> template <>
> const char* fmtspec<int> { return "%d"; }
>
> Or is there an easier method?

That's one approach. The other approach taken by a number of tests
is to pass the format specifier as an argument to the generic test
function and having the generic function pass it to rw_printf() or
rw_assert() as an argument to the "%{@}" directive. Like so:

     template <class T>
     void test_equal (T x, T y, int line, const char *fmt) {
         rw_assert (x == y, 0, line, "%{@} == %{@}, got %{@}",
                    fmt, x, fmt, y, fmt, y);
     }

     void test_equal_int () {
     #define TEST(x, y)   test_equal (x, y, __LINE__, "%d")

         TEST (1, 1);
         TEST (2, 2);
     }

As to the structure of the tuple tests, I'd like us to come up
with a generic function template that can verify the expected
effects of each tuple member function (including ctors). The
template will take a set of arguments to pass to the tuple
function, along with a description of the result and of the
observable effects (such as the number of calls of copy or
move ctors). Each test would call the function template
multiple times with different arguments to exercise all the
interesting test cases.

The description of the result could be just a character string
with the values of the tuple members. For example, for the ctor
tuple<int, int>(1, 2), the description of the expected result
could be "{1,2}" To implement the formatting in a general way
you might want to make use of the rw_printf() callbacks. See
test_user_defined_formatting() in the self/0.printf.cpp test.

The description of the observable effects can be as simple as
a couple of integers, one for the expected number of copy ctors
and the other for move ctors. Obviously, these can only be
verified for user-defined element types. To make sure we
exercise the primary template as well as any specializations
(such as tuple<T, T, T>) we'll need to use more than one user
defined type. E.g.,

     struct TupleElem {
         // ...
         int typid_;   // unique Id for each type
         int objid_;   // unique Id for each object

         // number of copy ctor invocations
         static int n_copy_ctors_;

         // number of move ctor invocations
         static int n_move_ctors_;

         // ...
     };

     template <int N>
     struct TupleElem: TupleElemBase { };

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.

Martin

[Eric Lemings-2]

 

> -----Original Message-----
> From: Martin Sebor [mailto:msebor@...] On Behalf Of Martin Sebor
> Sent: Friday, July 11, 2008 1:06 PM
> To: dev@...
> 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
>

...
>
> The description of the result could be just a character string
> with the values of the tuple members. For example, for the ctor
> tuple<int, int>(1, 2), the description of the expected result
> could be "{1,2}" To implement the formatting in a general way
> you might want to make use of the rw_printf() callbacks. See
> test_user_defined_formatting() in the self/0.printf.cpp test.

I was looking for a test that actually uses this user-definfed
formatting but couldn't find one.  Is there a use of this
formatting directive other than the test case in 0.printf.cpp?

Thanks,
Brad.

[Martin Sebor]

Eric Lemings wrote:

>  
>
>> -----Original Message-----
>> From: Martin Sebor [mailto:msebor@...] On Behalf Of Martin Sebor
>> Sent: Friday, July 11, 2008 1:06 PM
>> To: dev@...
>> 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
>>
> ...
>> The description of the result could be just a character string
>> with the values of the tuple members. For example, for the ctor
>> tuple<int, int>(1, 2), the description of the expected result
>> could be "{1,2}" To implement the formatting in a general way
>> you might want to make use of the rw_printf() callbacks. See
>> test_user_defined_formatting() in the self/0.printf.cpp test.
>
> I was looking for a test that actually uses this user-definfed
> formatting but couldn't find one.  Is there a use of this
> formatting directive other than the test case in 0.printf.cpp?

I think all or most of the tests that make use of the UserClass
class (in rw_value.h) do. The formatting function is defined in
value.cpp: _rw_fmtxarrayv().

Martin

>
> Thanks,
> Brad.

[Eric Lemings-2]

 

> -----Original Message-----
> From: Martin Sebor [mailto:msebor@...] On Behalf Of Martin Sebor
> Sent: Friday, July 11, 2008 1:06 PM
> To: dev@...
> 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.

Brad.

[Martin Sebor]

Eric Lemings wrote:

>  
>
>> -----Original Message-----
>> From: Martin Sebor [mailto:msebor@...] On Behalf Of Martin Sebor
>> Sent: Friday, July 11, 2008 1:06 PM
>> To: dev@...
>> 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

[Martin Sebor]

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 "???"; }
template <> const char* type_name<char>() { return "char"; }
template <> const char* type_name<short>() { return "short"; }
template <> const char* type_name<int>() { return "int"; }
// ...

template <class ...Types>
struct Name;

template <class T>
struct Name<T> {
     static void append (char* buf) {
         std::strcat (buf, type_name<T>());
     }
};

template <>
struct Name<> {
     static void append (char*) { }
};

template <class T, class ...Types>
struct Name<T, Types...> {
     static void append (char *buf) {
         std::strcat (buf, type_name<T>());
         std::strcat (buf, ", ");

         Name<Types...>::append (buf);
     }
};

template <class ...Types>
char* name (std::tuple<Types...>*)
{
     static char buf [256];

     std::strcpy (buf, "tuple<");

     Name<Types...>::append (buf);

     std::strcat (buf, ">");

     return buf;
}


Eric Lemings wrote:

>  
>
>> -----Original Message-----
>> From: Martin Sebor [mailto:msebor@...] On Behalf Of Martin Sebor
>> Sent: Friday, July 11, 2008 1:06 PM
>> To: dev@...
>> 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.
>
> Brad.

[Eric Lemings-2]

 

> -----Original Message-----
> From: Martin Sebor [mailto:msebor@...] On Behalf Of Martin Sebor
> Sent: Wednesday, July 16, 2008 11:11 PM
> To: dev@...
> 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
>
> Eric Lemings wrote:
> >  
> >
> >> -----Original Message-----
> >> From: Martin Sebor [mailto:msebor@...] On Behalf Of
> Martin Sebor
> >> Sent: Friday, July 11, 2008 1:06 PM
> >> To: dev@...
> >> 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.

It's not currently used.  I can remove it.

> 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.

> 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.

> 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?)

Was not aware of those.  I'll try to reuse them.

> 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.

It's not used either.  I can just remove it.

> 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.

I can do that.  It will make the code much more verbose but
also more explicit, as you say.
 
> 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.

You probably wouldn't want to do that since it would add symbols
to the RWTest library that would get linked into every test even
though they are only used in a handful of tests, namely the
tuple tests.

Regardless, its good practice so I have no problem doing this
either.

Brad.

[Eric Lemings-2]

 

> -----Original Message-----
> From: Martin Sebor [mailto:msebor@...] On Behalf Of Martin Sebor
> Sent: Wednesday, July 16, 2008 11:15 PM
> To: dev@...
> 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?

> template <> const char* type_name<char>() { return "char"; }
> template <> const char* type_name<short>() { return "short"; }
> template <> const char* type_name<int>() { return "int"; }
> // ...
>
> template <class ...Types>
> struct Name;
>
> template <class T>
> struct Name<T> {
>      static void append (char* buf) {
>          std::strcat (buf, type_name<T>());
>      }
> };
>
> template <>
> struct Name<> {
>      static void append (char*) { }
> };
>
> template <class T, class ...Types>
> struct Name<T, Types...> {
>      static void append (char *buf) {
>          std::strcat (buf, type_name<T>());
>          std::strcat (buf, ", ");
>
>          Name<Types...>::append (buf);
>      }
> };
>
> template <class ...Types>
> char* name (std::tuple<Types...>*)
> {
>      static char buf [256];
>
>      std::strcpy (buf, "tuple<");
>
>      Name<Types...>::append (buf);
>
>      std::strcat (buf, ">");
>
>      return buf;
> }

I started writing a compile-time version of this but it started to take
too long to write.  Now that I have some extra time though...  :)

Brad.

[Eric Lemings-2]

 

> -----Original Message-----
> From: Martin Sebor [mailto:msebor@...] On Behalf Of Martin Sebor
> Sent: Wednesday, July 16, 2008 11:15 PM
> To: dev@...
> 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
>

...
> template <class T, class ...Types>
> struct Name<T, Types...> {
>      static void append (char *buf) {
>          std::strcat (buf, type_name<T>());
>          std::strcat (buf, ", ");
>
>          Name<Types...>::append (buf);

Won't this result in an extra trailing ", "?  If there are no more
Types..., the last append is skipped.

Brad.

[Eric Lemings-2]

 

> -----Original Message-----
> From: Eric Lemings
> Sent: Thursday, July 17, 2008 8:47 AM
> To: 'dev@...'
> 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
>
>  

...
> > 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?)
>
> Was not aware of those.  I'll try to reuse them.

I believe this is a safe enhancement to rw_equal() but I just wanna make
sure:

template <class T, class U = T>
inline int rw_equal (T x, U y)
{
    return x == y;
}

This would allow comparison of different but compatible types which is
needed for heterogenous tuple types.  Anyone see a problem with it?

Brad.

[Eric Lemings-2]

 

> -----Original Message-----
> From: Eric Lemings
> Sent: Thursday, July 17, 2008 9:24 AM
> To: 'dev@...'
> 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
>
>  
>
> > -----Original Message-----
> > From: Eric Lemings
> > Sent: Thursday, July 17, 2008 8:47 AM
> > To: 'dev@...'
> > 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
> >
> >  
> ...
> > > 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?)
> >
> > Was not aware of those.  I'll try to reuse them.
>
> I believe this is a safe enhancement to rw_equal() but I just
> wanna make sure:
>
> template <class T, class U = T>
> inline int rw_equal (T x, U y)
> {
>     return x == y;
> }
>
> This would allow comparison of different but compatible types
> which is needed for heterogenous tuple types.  Anyone see a
> problem with it?

One problem with rw_equal(), as it relates to tuple tests, is that the
arguments are copied.  This poses a problem for user-defined types (esp.
UserDefined) which keeps track of and more importantly tests such
things.

I don't think it would be possible to change rw_equal() as follows:

template <class T, class U = T>
inline bool rw_equal (const T& x, const U& y)
{
    return x == y;
}

Or would it?

Brad.

[Martin Sebor]

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@...] On Behalf Of Martin Sebor
 >> Sent: Wednesday, July 16, 2008 11:15 PM
 >> To: dev@...
 >> 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

[Eric Lemings-2]

 

> -----Original Message-----
> From: Martin Sebor [mailto:sebor@...]
> Sent: Thursday, July 17, 2008 9:54 AM
> To: dev@...
> 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
>

...
>
> 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!

It's possible, but on second thought, it would probably require more
preprocessor magic than its worth to expand the individual string
literal components of a tuple name (or type list) which get concatenated
by the compiler.  Example:

"std::tuple<" "int" ", " "UserDefined" ">"

Brad.

[Martin Sebor]

Eric Lemings wrote:

>  
>
>> -----Original Message-----
>> From: Eric Lemings
>> Sent: Thursday, July 17, 2008 9:24 AM
>> To: 'dev@...'
>> 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
>>
>>  
>>
>>> -----Original Message-----
>>> From: Eric Lemings
>>> Sent: Thursday, July 17, 2008 8:47 AM
>>> To: 'dev@...'
>>> 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
>>>
>>>  
>> ...
>>>> 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?)
>>> Was not aware of those.  I'll try to reuse them.
>> I believe this is a safe enhancement to rw_equal() but I just
>> wanna make sure:
>>
>> template <class T, class U = T>
>> inline int rw_equal (T x, U y)
>> {
>>     return x == y;
>> }
>>
>> This would allow comparison of different but compatible types
>> which is needed for heterogenous tuple types.  Anyone see a
>> problem with it?
>
> One problem with rw_equal(), as it relates to tuple tests, is that the
> arguments are copied.  This poses a problem for user-defined types (esp.
> UserDefined) which keeps track of and more importantly tests such
> things.
>
> I don't think it would be possible to change rw_equal() as follows:
>
> template <class T, class U = T>
> inline bool rw_equal (const T& x, const U& y)
> {
>     return x == y;
> }
>
> Or would it?

I can't think of a reason why not (except for the default
template argument -- they're not allowed on functions; but
here the default isn't necessary).

>
> Brad.