Jeff Garland wrote:
The following is possible today:
std::string dst = range_construct(rng|to_upper); range_copy(rng|to_upper|to_lower|to_upper, dst);
Note that '|to_upper' is lazy. I have no idea what this code does? Construct a range from chars that have been upper-cased and write it into dst. Then copy the rng to while converting it to upper, then lower, then upper? This one isn't winning me over with code clarity... '|to_upper' makes a range of 'transform_iterator'.
Honestly, that didn't clear it up for me. What does the rest of it do? This code doesn't make sense to me: 'to_upper|to_lower|to_upper' It's upper, then lower, then upper -- huh?
'to_upper` is called a range adaptor. The pitiful iterators do what you mentioned. That code is somewhat kidding. :-)
Well, IMHO, I prefer free-functions for another readability:
or s1.replace_all(s2, s3); //obvious which string is modified here
Of course, you want to be able to work consistently so you have to pull along the functions with less arguments too.
The main problem is that 's1' must be a 'super_string'.
Yep that's true it does. But, you know, that's what I'm writing code for -- strings of chars. I don't really need the particular code I'm writing to handle every possible type in the world -- just strings of chars. If you aren't processing strings, then don't use super_string. Pavol and John have taken care of all the generic cases. I'm reducing things down to the common and frequent thing that I need to do. And the thing is, there's still nothing stopping me from writing
super_string s(...); some_free_function_algorithm_here(s, ...);
So what have I lost? Nothing. I've gained cleaner, clearer code for the things I do every day -- code I can explain to any programmer. There isn't a single novel algorithm or function in super_string -- I've just optimized the generic code for the common cases I need by wrapping up a couple of existing Boost libraries.
Right. 'super_string' can be used as 'Sequence' and 'Range'. IIRC, I see your proposal is no radical and related to the language feature proposal which makes users have the choice of: 'foo(a);' or 'a.foo();'
The 'Range' and 'Sequence' abstractions will disappear. How does this look? :-)
replace_all(out(s1), in(s2), in(s3));
Better, but it's still ugly in comparison. I could give the first one to just about any programmer (even non-c++) and they would get it. With your example I'm sure lots of programmers will be scratching there heads. They'll be distracted by the 'in' and 'out'. I certainly am.
I agree we should appreciate non-c++ programmers. Actually range adaptors looks influenced by unix pipe syntax. -- Shunsuke Sogame