incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Lemings" <Eric.Lemi...@roguewave.com>
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
Date Wed, 09 Jul 2008 17:07:08 GMT
 

> -----Original Message-----
> From: Travis Vitek [mailto:Travis.Vitek@roguewave.com] 
> Sent: Tuesday, July 08, 2008 6:04 PM
> To: dev@stdcxx.apache.org
> 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.

Mime
View raw message