Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk