Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of AntonP@moscow.vdiweb.com
 designates 195.210.189.132 as permitted sender)
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: Thu, 8 Jun 2006 19:21:07 +0400
Message-ID: <4D6A8407B7AC6F4D95B0E55C4E7C4C62045BCE4E@exmsk.moscow.vdiweb.com>
Thread-Topic: svn commit: r412249 - in /incubator/stdcxx/trunk/tests:
 include/21.strings.h src/21.strings.cpp
Thread-Index: AcaKezO+7KFUkMIWTkKY5JCakMWqVAAkan1Q
From: "Anton Pevtsov" <AntonP@moscow.vdiweb.com>
To: <stdcxx-dev@incubator.apache.org>

Martin Sebor wrote:
> I think this would be an overall improvement to the class so with the
change above please go ahead and commit.

Committed here: http://svn.apache.org/viewvc?rev=3D412750&view=3Drev
Now I am applying the same changes to the cons test.

Martin Sebor wrote:
> You mean make the derived class virtual operator() call append,
[...]
> this design would expose us to the problem I'm trying to prevent.

Ok, I see. I think we may leave the design as is at this time.=20
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?

Thanks,
Anton Pevtsov.


-----Original Message-----
From: Martin Sebor [mailto:sebor@roguewave.com]=20
Sent: Thursday, June 08, 2006 01: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:
> Martin, I suggest to move the common to all range overlodas for=20
> different methods code to the 21.strings.h I think we may have=20
> RangeBase class with begin methods and virtual operator ().
> Here are the changes to the tests which use this approach:
> http://people.apache.org/~antonp/stdcxx06072006/

I agree, it's a good idea to move the base class to a common header. The
only thing that needs to change if we do that is that we will either
need #include <string> in that header to bring in the declaration of
basic_string, or replace it with just String. I.e., change RangeBase to

   template <class String>
   struct RangeBase {
       ...
   };

I think this would be an overall improvement to the class so with the
change above please go ahead and commit.

>=20
> The rest of the code in classes which exrcise range methods look=20
> similar too. So it is possible to join them and use the func_id to=20
> determine which of the string methods should be called. What do you=20
> think about this?

You mean make the derived class virtual operator() call append, assign,
insert, erase, or insert based on func_id and move the whole thing to
the header as well? My philosophy of where to draw the line between how
much code to move into the driver and how much to leave in each test has
been driven by the desire to prevent failures across all or many tests
caused by problems in a library component that should not otherwise
affect them. For example, if basic_string::insert<InputIterator>() had a
bug that prevented it from compiling that bug should not cause
compilation errors in tests exercising other template members. Since
merging all the derived classes into one would cause the instantiation
of calls to all members referenced in the derived class operator() this
design would expose us to the problem I'm trying to prevent.

Martin