----- Original Message ----- From: "Pavol Droba" <[EMAIL PROTECTED]>
> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost