> -----Original Message----- > From: Travis Vitek [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 08, 2008 6:04 PM > To: [email protected] > Subject: 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.cpp > > ... > > The commented unused argument names again. Also, I think the > _RWSTD_SPECIALIZED_FUNCTION macro can be eliminated. If I remember > correctly Martin asked that it be removed from the traits > implementation (which I've done).
I've been using _TYPENAME, _EXPLICIT, and _RWSTD_SPECIALIZED_FUNCTION just to be consistent with existing code. Is there a good reason not to do this anymore? (Actually I can think of one but I'll see if anyone else can think of it and/or another.) > ... > Is there any way that we could write a routine to generate a tuple and > then test it, so as to avoid always using the same few types > and values > hidden behind the *_VALUE macros? The usage would be something like > this... > > TEST_TUPLE (1, 3.14f, 'a', "abc"); This might work for homogenous tuples where the element types can be deduced from the values. Not sure exactly how you would fit user-defined (e.g. UserClass) values into it. Also, you'd need an expanded form for heterogenous tuples where the compatible/convertible types would have to be explicitly specified. For this latest update, I really wanted to just get a complete set of tests in there however verbose they may be. > > >- int i = 1; > >- IntTuple it1 (i); _RWSTD_UNUSED (it1); > >- const IntTuple it2 (i); _RWSTD_UNUSED (it2); > >- ConstIntTuple ct (i); _RWSTD_UNUSED (ct); > >- IntRefTuple rt (i); _RWSTD_UNUSED (rt); > > > >- NestedTuple nt (it2); _RWSTD_UNUSED (nt); > >+#define USER_VALUE user_val > > I'm being a nit-picker, but this seems like an awful simple > thing to be > wrapping a macro around. Is there a reason to do so? Like the other value macros, to hide the actual value being used and to provide a single point of definition where it can be modified. > > >Modified: stdcxx/branches/4.3.x/tests/utilities/20.tuple.creation.cpp ... > >+ rw_assert (0 == std::strcmp (s, "string"), __FILE__, __LINE__, > >+ "s == \"string\", got false, expected true"); > > The tuple is holding the original pointer (not a copy), so I think you > can check the actual pointer here. True. But if that assumption became invalid for whatever reason, the code above would still work. Assumptions are bad. Robustness is good. :) Brad.
