Hi, Am 24.01.2017 13:12, schrieb Richard Hodges:
The second version I reject regardless, because it uses an overloaded operator |.
That is the adaptor API from boost::range and is the same in ranges::v3. It's not my invention.
I must admit that I share Hans' distaste of the pipe overloads.
As I said, this is not my invention. That notation is used with boost::ranges and ranges::v3 and has good chances to be part of the C++ standard library in future. At least the committee seems to discuss ranges::v3.
I also strongly feel that .str() is an error, since it couples the concepts of strings with joiners, or concatenators. Strings have allocators and traits. I feel that a free function is more decoupled, and could even go in a separate header file to reduce complexity.
The allocator could be given with a parameter : concat(...).str(my_allocator); We could have a character type as template parameter, which might default to char: concat(...).str<wchar>(my_allocator); The whole discussion started with a question for a concat() like function, that would return std::string. Therefore I don't feel too embarrassed, that up to now we came up with stuff, that is coupled to produce strings.
to_string(x) is better than x.str() is better than implicit conversion.
Maybe it is just my strong distaste of the name to_string(), which at the moment is just a feeling, no good reasons. It just feels clumsy to me, while .str() is in line with regular expression matches, and stringstreams in the standard library. Christof