Anton Pevtsov wrote:
Martin Sebor wrote:
I think we should be able to accommodate find without adding the new
TestCase member, though. Instead we can reuse res_len. Feel free to
rename it to reflect its dual purpose.
Hmm. I think it will be inconvenient. For example, the possible value
returned by the compare method may be any integer, positive or negative.
So we will run into conversions between size_t and int (res_len has type
size_t). Will the code with these conversions be more effective than the
code with extra member in the sructure?
I'm not sure what you mean by "effective" but we can certainly
change the type of the integer member from size_t to plain old
int to handle the special case of compare. It seems like overkill
to add a whole new data member (and change all existing tests)
just to accommodate a single member function (find returns
size_type), especially given our already established policy of
dual-purposing members for two functions (e.g., for the offset
and iterator members).
In summary, unless there are member functions yet to be tested
that would necessitate adding this new member (can you think of
any?) I don't think the compare argument is compelling enough.
Martin
Updated tests are here:
http://people.apache.org/~antonp/stdcxx04272006/
Also there are new updated test : 21.string.erase.cpp and tests for all
find methods.
In this version I kept nres on its place.
Martin Sebor wrote:
One other request: could you please change all occurrences of charT in
the comments to read value_type and remove the formal argument?
Done.
The change log:
2006-04-27 Anton Pevtsov <[EMAIL PROTECTED]>
* 21.strings.h (SignatureId): Added missed signatures.
(MemberId): Added elements for erase, find, rfind, etc,
set start of elements to 1 << 6 because there are more than
32 signatures.
(OverloadId): Added elements for find, rfind, etc overloads.
(TestCase): Added nres member to keep expected results
than an integer value is expected.
* 21.strings.cpp (_rw_memfun_names): Added names for
find, rfind, find_first_of, etc methods.
(_rw_setvars): Added missed signatures to the signatures array,
added cases for erase method and find methods overloads.
(run_test): Added options for new signatures.
* 21.string.erase.cpp (MemFun, EraseTags): Removed as
obsolete.
(void_test_cases, size_test_cases, etc): New arrays of the
test cases to exercise erase overloads.
(test_erase): Rewrote to use test cases arrays, exception
handling updated.
(main): Updated to use new test driver features.
* 21.string.append.cpp (ptr_test_cases, str_test_cases, etc):
Added default value for new TestCase member nres, set to -1
for all test case arrays, signature descriptions updated.
(test_append): Removed obsolete declaration
* 21.string.assign.cpp: Same
* 21.string.insert.cpp: Same
* 21.string.op.plus.eq.cpp: Same
* 21.string.replace.cpp: Same
Thanks,
Anton Pevtsov
-----Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 26, 2006 20:22
To: [email protected]
Subject: Re: Tests for lib.string::find methods
Anton Pevtsov wrote:
Martin, I updated test for the find method. It required several minor
changes to 21.strings.cpp and 21.strings.h. The most important - I
added "int nres" member to the TestCase structure and updated the
existing tests properly.
The difference files and new test are here:
http://people.apache.org/~antonp/stdcxx04262006/
I hope there will be no problems to access them.
No problems. The changes look pretty good. I think we should be able to
accommodate find without adding the new TestCase member, though. Instead
we can reuse res_len. Feel free to rename it to reflect its dual
purpose.
One other request: could you please change all occurrences of charT in
the comments to read value_type and remove the formal argument?
E.g., change:
find (const charT* s)
to
find (const value_type*)
With these changes please go ahead and commit.
[...]
And there is small question - does stdcxx support 16-bit
architectures?
It should, even though we're not testing on any at the moment.
If yes we should modify MemberId enum elements to keep them less than
1 << 16.
The underlying type for a C++ emum is required to be wide enough to fit
the largest enumerator regardless of the hardware so this should not be
a concern on conforming implementations.
Martin
