Subject: Re: [boost] Variadic append for std::string
From: Christof Donat (cd_at_[hidden])
Date: 2017-01-25 11:23:13
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