Tests for string non-members - operators

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

Ported test for std::string non-members operators (+, ==, != , <=, >=,
<, >) are here:
http://people.apache.org/~antonp/stdcxx05252006b/

Also there are required differences to strings.h/.cpp.

I noticed two problems with non-members:

1) _rw_sigcat forms incorrect formatted strings for non-members. The
cause is in additional shift in the for cycle:
    for (size_t argno = 0; argmap >>= Ids::arg_bits; ++argno) {

I guess it was done to process "self" flag bits for members.
I implemented workaround using NON_MEMBER_(N) (f, void, arg1, arg2, ...)
instead of NON_MEMBER_(N - 1) (f, arg1, arg2, ...) , i.e. definnig the
following:

#define NON_MEMBER_2(f, a, b) \
        FID_2 (f, a, b) = SIG_3 (f, void, a, b)

But maybe there is another way to solve this problem...

2) The "=" symbol in _rw_func_names array brokes the command line
arguments parsing. I tried "operator==", "operator!=", etc and this
didn't work and
I used synonyms: "operator_equal", "operator_not_equal", etc instead. Is
there any way to allow the "=" using in operator's names?

Change Log:
2006-05-25  Anton Pevtsov <an...@moscow.vdiweb.com>

	* 21.strings.h (FuncId): Added new elements for non-members
	(NON_MEMBER_N): Changed to use SIG_N + 1 (f, void, a, ...) to 
	workaround problem with additional shift in _rw_sigcat.
	(OverloadId): Added new elements for non-members operators.
	* 21.strings.cpp (_rw_func_names): Added  new elements for 
	non-members operators - synonyms to avoid problems with
	command line arguments parsing
	(_rw_setvars): Updated to use full template arguments lis for
UserAlloc,
	method "header" format updated for non-members, added new cases
	for new OverloadId elements.


Also I suggest to extend the FuncId to 6 bits: there are at least 6
methods left (from the capacity test, begin(), end(), etc).
What do you think about this?


Thanks,
Anton Pevtsov

Re: Tests for string non-members - operators

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

Anton Pevtsov wrote:
> Ported test for std::string non-members operators (+, ==, != , <=, >=,
> <, >) are here:
> http://people.apache.org/~antonp/stdcxx05252006b/

Would you mind terribly merging all the [in]equality and relational
tests and keep just the one for operator+() separate? The code for
all them is identical save for the invocation of the actual function
and the test cases are all pretty much the same as well, with the
only difference being the result. We can encode the result the same
way as for compare (i.e., -1 less, 0 equal, +1 greater) and have
the main test function determine the expected outcome for each
function from this value.

> 
> Also there are required differences to strings.h/.cpp.
> 
> I noticed two problems with non-members:
> 
> 1) _rw_sigcat forms incorrect formatted strings for non-members.

Yes, it's not quite correct. What we need is a way to distinguish
members from non-members. E.g., a bit in SigId. But I suspect that
won't be the only problem: _rw_setvars() will need to change to
distinguish between members and non-members as well.

> The
> cause is in additional shift in the for cycle:
>     for (size_t argno = 0; argmap >>= Ids::arg_bits; ++argno) {
> 
> I guess it was done to process "self" flag bits for members.
> I implemented workaround using NON_MEMBER_(N) (f, void, arg1, arg2, ...)
> instead of NON_MEMBER_(N - 1) (f, arg1, arg2, ...) , i.e. definnig the
> following:
> 
> #define NON_MEMBER_2(f, a, b) \
>         FID_2 (f, a, b) = SIG_3 (f, void, a, b)
> 
> But maybe there is another way to solve this problem...

This would work, too, but since we have those three extra bits it
seems we might as well put one of them to good use and not waste
a whole argument field on it.

> 
> 2) The "=" symbol in _rw_func_names array brokes the command line
> arguments parsing. I tried "operator==", "operator!=", etc and this
> didn't work and
> I used synonyms: "operator_equal", "operator_not_equal", etc instead. Is
> there any way to allow the "=" using in operator's names?

Hmm, I don't believe so. I might be able to tweak the parser to
accept an escaped equals sign (e.g., "--enable-operator\=") but
I'm not sure that's what we want. A better option might be to
translate special characters such as the equals sign to some
mnemonic akin to what we do with argument types. E.g.,"operator="
would become "op_assign" (btw., I think we might want to rename
fid_op_set to fid_op_assign since the name of the function is
"the assignment operator").

Okay, I made the changes I described above (and a few more) and
committed them with this change:
http://svn.apache.org/viewvc?rev=409484&view=rev


Martin