Re: [boost] String algorithm library

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2002-11-16 15:43:37

----- Original Message -----
From: "Pavol Droba" <droba_at_[hidden]>

> On Fri, Nov 15, 2002 at 06:47:35PM +0100, Thorsten Ottosen wrote:
> > I would find it more naturally to say
> >
> > string s = ...;
> > trim( s );
> >
> > than to use 'trim_in()'.
[snip]
> Well I have reasons to put it in the way I did. Rationale was to allow
usage of the
> functions in fuctional way. I consider it quite natural to write something
like
>
> if ( to_lower(trim(s)) == "OK" )
> {
> // do somethign with original s
> }
>
> There are many cases like this in which you probably don't want modify
input sequence.
> So in the functional approach when you usualy stack multiple
transformation in one line
> especialy in conditions. When expression gets complicated it could be
quite anoying and
> less readable to use variants with suffix of prefix.

Perhaps one could use these names then:

Seq  trimmed(...);
void trim(...);
>    Seq trim( const Seq& Input, const std::locale& Loc=std::locale() )
>    Seq& trim_in( Seq& Input, const std::locale& Loc=std::locale() )

and

Seq lower_cased(...);
void to_lower_case(...);

Seq  upper_cased(...);
void to_upper_case(...);

>    Seq tolower( const Seq& Input, const std::locale& Loc=std::locale() )
>    Seq& tolower_in( Seq& Input, const std::locale& Loc=std::locale() )

>    Seq toupper( const Seq& Input, const std::locale& Loc=std::locale() )
>    Seq& toupper_in( Seq& Input, const std::locale& Loc=std::locale() )

Your example would become

if ( lower_cased( trimmed( s ) ) = "ok" )

> maybe the suffix _in is not the best, and i'm open to any suggestions, but
I like you to
> consider my reasons to keep non-modifying variants as default.

Of course, just consider them suggestions :-)

> > What is relevant here is that the code below does not call
.begin()/.end(),
> > but overloaded
> > freestanding begin() / end() functions. If your code should work with
char
> > arrays or iterator ranges,
> > then you could benefit from the container algo. begin/end functions
> > approach. However, there is a big problem, namely that
> > the container algorithms don't work on eg. VC6/7.
>
> This sounds interesting. I have seen your library in the sandbox, and I've
even
> written a mail to Jeremy who I thought is a co-author of the lib.
He is. But he's pretty busy (aren't we all?). Anyway, it was Jeremy's idea
to
use free standing functions s.t. pairs of iterators could be used and he
laid the basic
tagging mechanism. The free-standing functions also made array support
possible (which will make builtin arrays a _lot_
more useful), so I added that and implemented most of the algorithmic stuff
and a
1000+ lines of test. We still need concept checks and some assertions, but
it has to way till
the traits are running on more platforms.

> I'm open to any ideas, but I consider compatibility with compiler like
VC6/7
> as an important issue. But I coudl be possible to #ifdef sensitible code
and
> keep at least the core of the lib to be usable for everyone.
>
> It would be nice If you can provide me with more details about your work.

As I see it, the free standing begin()/end() stuff would be beneficial to
you, and perhaps
many others. Let's assume that they we're working. Then you would implement
the iterator range version of the algorithms (as you already did) and the
forwarding
in the container versions would use the free-standing begin()/end() and you
would automatically
get support for pair of iterators and arrays too.

I guess we could just make some defines at present s.t. you could use
begin/end in your code
and on compilers with enough support one would be able to use everything.

In that case I guess the traits should be moved to a seperate header, to
make it more appropriate
for different libraries to use it. BTW, the array_traits was written a long
time ago by Dietmar Kuehl.

Anyway, I think the main problem is this statement:

template< typename T, size_t >
struct some_traits;

template< typename T, size_t sz >
struct some_traits< T[sz] >; // bad bad bad on vc6/7

Unfortunately I don't know a workaround :-(.

regards

--Thorsten