stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anton Pevtsov" <Ant...@moscow.vdiweb.com>
Subject RE: svn commit: r412249 - in /incubator/stdcxx/trunk/tests: include/21.strings.h src/21.strings.cpp
Date Fri, 09 Jun 2006 14:06:05 GMT
Here are the diffs to the ctor test required by the testing of the range
overloads:
http://people.apache.org/~antonp/stdcxx06092006/

Martin Sebor wrote:
>PS It seems that implementing it in the driver shouldn't be too
difficult. Reversing the substring of the expected result string that
corresponds to range argument of the modifying function should   >do it,
don't you think?

Yes it is possible to reverse the expanded substring in known range, but
we check results in other way:

	std::size_t match = rw_match (tcase.res, str.data (),
tcase.nres);

Here the rw_match calls rw_expand. These functions know nothing about
the iterators and range bounds and this seems to be a problem.


Thanks,
Anton Pevtsov.


-----Original Message-----
From: Martin Sebor [mailto:sebor@roguewave.com] 
Sent: Thursday, June 08, 2006 23:41
To: stdcxx-dev@incubator.apache.org
Subject: Re: svn commit: r412249 - in /incubator/stdcxx/trunk/tests:
include/21.strings.h src/21.strings.cpp


Anton Pevtsov wrote:
[...]
> Ok, I see. I think we may leave the design as is at this time.
> But there is a problem with reverse iterators. It looks like we should
> provide special resulting sequence for them.
> What do you think about this?

Yeah, I realize the reverse iterators don't quite fit in and need some
sort of special treatment. The problem is that we currently have no way
to specify a set of test cases to exercise just this and no other
iterator categories.

I think we have at least the following three options for how to deal
with reverse iterators:

1. Do nothing (i.e., avoid using them for testing).

2. Change the StringTest struct to let us designate sets of test cases
intended only for reverse iterators.

3. Change the driver to create a new StringTestCase object from the
hardcoded one with the expected result in the reverse_iterator case
(i.e., before invoking the test function with a StringFunc::iter_id_ of
ReverseIter).

I'm not too crazy about option (2) since it feels like a hack (do you
have any arguments for going with it?) so for me it really comes down to
either (1) or (3). I guess we can leave it for now, unless you have a
burning desire to implement it, and come back to it if and when we're
done with other more important things.

Martin

PS It seems that implementing it in the driver shouldn't be too
difficult. Reversing the substring of the expected result string that
corresponds to range argument of the modifying function should do it,
don't you think?

Mime
View raw message