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