Jeff Garland wrote:
Shunsuke Sogame wrote:
Jeff Garland wrote:
Apart from optimization, the future (under range proposal) 'to_upper' might be:
std::vector<char> const rng; std::string dst(rng|to_upper);
Sorta hard for me to anticipate the future ;-) Anyway, I assume rng can be an std::string as well?
'std::string' will be constructed from any "rng" in the far distant future... :-) I also can't wait for the future Boost.Range, I'm working for my own use: http://tinyurl.com/p8e4m Note that they are not fully implemented yet.
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'.
Well, IMHO, I prefer free-functions for another readability:
::CString rng; boost::to_upper(rng);
std::vector<char> rng; boost::to_upper(rng);
super_string str; str.to_upper(); // !
In the zero/one argument case there's no significant advantage. So I'll repeat this case again:
std::string s1("foo"); std::string s2("bar); std::string s3("foo"); //The next line makes me go read the docs again, every time replace_all(s1,s2,s3); //which string is modified exactly? 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'. The 'Range' and 'Sequence' abstractions will disappear. How does this look? :-) replace_all(out(s1), in(s2), in(s3)); -- Shunsuke Sogame