incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: Tests for lib.string::find methods
Date Thu, 27 Apr 2006 18:24:39 GMT
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 <antonp@moscow.vdiweb.com>
> 
> 	*  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:sebor@roguewave.com] 
> Sent: Wednesday, April 26, 2006 20:22
> To: stdcxx-dev@incubator.apache.org
> 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


Mime
View raw message