Re: [boost] String algorithm library

From: Pavol Droba (droba_at_[hidden])
Date: 2002-11-16 17:43:21

> 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" )
> 

This naming sounds good enough, just I'm not sure if such a difference between
two variants would not make the code less readable. Alfter all both of them are doing
the same thing.

What I don't get is why are you proposing to change return value from Seq& to void.
I think it is easier fo write

to_lower(trim(to_upper(s)));

then

to_upper(s); trim(s); to_lower(s);

> >
> > 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.

Well what I do now is to move the usage of .begin() and .end() outside from the functions,
so they can be adapted to your lib when it will be ready. I can you defines as you are
proposing for instance. There could be a define which would allow user to choose which
version to use. That way it would leave the way open for your impoved version and it would 
still be possible to use it on a platform where new containter lib is not available.
I'll try to think about it, it should not be a big deal.

Anyway I would definitely like to support your container lib. I like it and it would 
add an interesting functionality to the string lib with almost no cost.

> 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 :-(.

I haven't tried to add traits to my lib yet. But as I see from discussion I would prefer
to have them as something optional so that the compatibility issues with some compilers would
not cause the lib unusable.

Regards,

Pavol