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()'.
> 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
> 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
> 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 trim( const Seq& Input, const std::locale& Loc=std::locale() )
> Seq& trim_in( Seq& Input, const std::locale& Loc=std::locale() )
> 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
> > but overloaded
> > freestanding begin() / end() functions. If your code should work with
> > 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
> 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
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
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
> as an important issue. But I coudl be possible to #ifdef sensitible code
> 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
in the container versions would use the free-standing begin()/end() and you
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 >
template< typename T, size_t sz >
struct some_traits< T[sz] >; // bad bad bad on vc6/7
Unfortunately I don't know a workaround :-(.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk