Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of AntonP@moscow.vdiweb.com
 designates 195.210.189.132 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: test for lib.string::operator+
Date: Fri, 19 May 2006 18:46:33 +0400
Message-ID: <4D6A8407B7AC6F4D95B0E55C4E7C4C62043B0AA2@exmsk.moscow.vdiweb.com>
Thread-Topic: test for lib.string::operator+
Thread-Index: AcZ654S1ZwDk6M76ROualXiEJKWRYAAWWUzw
From: "Anton Pevtsov" <AntonP@moscow.vdiweb.com>
To: <stdcxx-dev@incubator.apache.org>

Martin Sebor wrote:
[...]
> I also think we can do better than hardcode assumptions about the
order of the constants (the computation of the nonmember constant in
21.strings.cpp).

Hmm, shall we separate members indexes or enum elements (and
signatures?) from the nonmember ones?=20

Or we may have something like=20

struct OverloadId {
	MethodId method_id;
	SignatureId signature_id;
};

where MethodId enum is organized like SignatureId and includes all
methods, operators (including non-memebres) to be tested?


Thanks,
Anton Pevtsov


-----Original Message-----
From: Martin Sebor [mailto:sebor@roguewave.com]=20
Sent: Friday, May 19, 2006 05:57
To: stdcxx-dev@incubator.apache.org
Subject: Re: test for lib.string::operator+


Anton Pevtsov wrote:
> The ported test for lib.string::operator+ is here:=20
> http://people.apache.org/~antonp/stdcxx05182006/
>=20
> Also there are required changes to 21.strings.h/cpp files: 5 new=20
> signatures and memberId element, etc.

Okay, this looks okay to commit, although I think we will need to
something about the non-members. They don't seem to fit in StringMembers
for a rather obvious reason ;-) The mem_xxx naming convention is also
based on "membership" so it seems funny to be using it for free standing
functions.

I also think we can do better than hardcode assumptions about the order
of the constants (the computation of the nonmember constant in
21.strings.cpp).

>=20
> But we are going to run out of bits in the MemberId enumeration, and=20
> it blocks the rest of the tests porting. I think we may transform the=20
> overloadId to the structure with 2 fields: memberId and signatureId.
> I can implement this if you agree. What do you think about this?

Yes, I think that's a sensible approach.

>=20
> Also there is another question: shall we keep all non-members tests in

> one cpp file or in several files like for the find methods done?

I would be inclined to follow the established structure of one test per
overload.

Martin