stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anton Pevtsov" <Ant...@moscow.vdiweb.com>
Subject RE: test for lib.string::operator+
Date Fri, 19 May 2006 14:46:33 GMT
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? 

Or we may have something like 

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] 
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: 
> http://people.apache.org/~antonp/stdcxx05182006/
> 
> Also there are required changes to 21.strings.h/cpp files: 5 new 
> 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).

> 
> But we are going to run out of bits in the MemberId enumeration, and 
> it blocks the rest of the tests porting. I think we may transform the 
> 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.

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

Mime
View raw message