Boost logo

Boost :

Subject: Re: [boost] Variadic append for std::string
From: Christof Donat (cd_at_[hidden])
Date: 2017-01-03 10:55:21


Hi,

Am 03.01.2017 16:08, schrieb Olaf van der Spek:
>>> How about this one?
>>>
>>> throw std::runtime_error("Error "s << 47);
>>
>>
>> Uh. How does that work with
>>
>> std::cout << "Error "s << 47;
>>
>> Will that be
>>
>> (std::cout << "Error "s) << 47;
>>
>> or
>>
>> std::cout << ("Error "s << 47);
>
> We've got rules for that..
> http://en.cppreference.com/w/cpp/language/operator_precedence

I know, but you came up with C++ beginners. They already often get
confused
with streams and bit shifts, mostly when they come to C++ from C. Now we
additionally mix expressions, where we can use manipulators with those,
where we can't. That will probably make things worse not only for C++
beginners.

>> Also I'd expect a std::string to behave like a stream then and try to
>> use e.g. manipulators. Maybe that would be acceptable with a different
>> operator. e.g. like in SQL:
>>
>> throw std::runtime_error("Error "s || 47);
>>
>> Now this is explicit:
>>
>> std::cout << "Error "s || 47; // versus
>
> Why would you want to combine << for ostream and string? Just use the
> ostream one in both cases.

We just came across the idea, that appending to the string will be
faster
than writing to a stream. Therefore it might be a good idea to put
together the string with appending and then hand the complete result to
the stream.

Anyway, the syntax I proposed would at least make the difference
explicit
for the reader. The programmer expresses the intent to either first
concatenate the strings and then write to the stream or write to the
stream directly.

> I think << is quite elegant.

I feel very uneasy with it and I think I have presented quite some
reasoning why. Also I don't seem to be the only one in this discussion.
At least that should count as a strong indicator, that you need much
better reasons to back your proposal.

Christof


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