stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anton Pevtsov" <>
Subject RE: Tests for string non-members - operators
Date Fri, 26 May 2006 14:17:52 GMT
Martin Sebor wrote:
> Would you mind terribly merging all the [in]equality and relational
tests and keep just the one for operator+() separate? 

The merged operators test (21.string.operators) and separate test for
operator+ are here:

With best wishes,
Anton Pevtsov

-----Original Message-----
From: Martin Sebor [] 
Sent: Friday, May 26, 2006 02:30
Subject: Re: Tests for string non-members - operators

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

> 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