From stdcxx-dev-return-1513-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org Fri Jun 09 14:06:26 2006 Return-Path: Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org Received: (qmail 15839 invoked from network); 9 Jun 2006 14:06:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 9 Jun 2006 14:06:26 -0000 Received: (qmail 38605 invoked by uid 500); 9 Jun 2006 14:06:25 -0000 Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org Received: (qmail 38590 invoked by uid 500); 9 Jun 2006 14:06:25 -0000 Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: stdcxx-dev@incubator.apache.org Delivered-To: mailing list stdcxx-dev@incubator.apache.org Received: (qmail 38579 invoked by uid 99); 9 Jun 2006 14:06:25 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Jun 2006 07:06:25 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of AntonP@moscow.vdiweb.com designates 195.210.189.132 as permitted sender) Received: from [195.210.189.132] (HELO mail.moscow.vdiweb.com) (195.210.189.132) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Jun 2006 07:06:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: svn commit: r412249 - in /incubator/stdcxx/trunk/tests: include/21.strings.h src/21.strings.cpp Date: Fri, 9 Jun 2006 18:06:05 +0400 Message-ID: <4D6A8407B7AC6F4D95B0E55C4E7C4C62045BD64B@exmsk.moscow.vdiweb.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: svn commit: r412249 - in /incubator/stdcxx/trunk/tests: include/21.strings.h src/21.strings.cpp Thread-Index: AcaLM46QXx0LuCEWQaqiWYib4No1nAAmICvg From: "Anton Pevtsov" To: X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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 =3D 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]=20 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?