stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: Tests for string non-members - operators
Date Thu, 25 May 2006 22:29:31 GMT
Anton Pevtsov wrote:
> Ported test for std::string non-members operators (+, ==, != , <=, >=,
> <, >) are here:

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:


View raw message