test for lib.string::operator+

[Anton Pevtsov <An...@moscow.vdiweb.com>]

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.

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?

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?

Thanks,
Anton Pevtsov

Re: test for lib.string::operator+

[Martin Sebor <se...@roguewave.com>]

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