Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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, 9 Jul 2008 11:07:08 -0600
Message-ID: 
 <CFFDD219128FD94FB4F92B99F52D0A4901DB0638@exchmail01.Blue.Roguewave.Com>
Thread-Topic: 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
Thread-Index: AcjhUHjBx2jJV/psQR+A5lb/aX/PGwAAbPOAACScKSA=
References: <20080708231336.C38872388A22@eris.apache.org>
 <CFFDD219128FD94FB4F92B99F52D0A4901E0FC1B@exchmail01.Blue.Roguewave.Com>
From: "Eric Lemings" <Eric.Lemings@roguewave.com>
To: <dev@stdcxx.apache.org>

=20

> -----Original Message-----
> From: Travis Vitek [mailto:Travis.Vitek@roguewave.com]=20
> Sent: Tuesday, July 08, 2008 6:04 PM
> To: dev@stdcxx.apache.org
> Subject: RE: svn commit: r675044 - in /stdcxx/branches/4.3.x:=20
> include/rw/_tuple.h include/tuple=20
> tests/utilities/20.tuple.cnstr.cpp=20
> tests/utilities/20.tuple.creation.cpp=20
> tests/utilities/20.tuple.h tests/utilities/20.tuple.helpers.cpp
>=20
> =20
...
>=20
> 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=20
> 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.)

>=20
...
> 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=20
> and values
> hidden behind the *_VALUE macros? The usage would be something like
> this...
>=20
>   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.

>=20
> >-    int i =3D 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);
> >=20
> >-    NestedTuple nt (it2); _RWSTD_UNUSED (nt);
> >+#define USER_VALUE      user_val
>=20
> I'm being a nit-picker, but this seems like an awful simple=20
> 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.

>=20
> >Modified: stdcxx/branches/4.3.x/tests/utilities/20.tuple.creation.cpp
...
> >+    rw_assert (0 =3D=3D std::strcmp (s, "string"), __FILE__, =
__LINE__,
> >+               "s =3D=3D \"string\", got false, expected true");
>=20
> 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.