From: Ed Brey (brey_at_[hidden])
Date: 2003-06-03 08:48:36
Thomas Witt wrote:
> 1. std::endl was and is still abused heavily. I think there is a
> reason for this. Most c++ programmers are taught to stay clear of
> ugly low-level c things and to use the new shiny c++ facilities
> instead. And that's what they do, replace '\n' with std::endl.
> Personally I believe this reason alone justifies a std library
> extension std::newl.
What are your thoughts on the "shininess" of std::newl? To me, newl still seems kind of cryptic, not much better than '\n'. Is the extra verbosity worth the downsides? I see a few downsides:
* The general aliasing problem of having two ways to accomplish basically the same thing ('\n' and newl) - it increases stylistic variances between different pieces of code and means a higher learning curve for those who now have to know two constructs to read existing code.
* We currently have two constructs with different semantics, where the name doesn't provide any hint of the difference between those semantics: endl and '\n'. Do we really want to add one more such unhinting name to the hat. How is the user to be reminded that '\n' and newl are almost the same, but not quite, whereas endl is the manipulator that provides the flush?
* Since only '\n' works when forming strings, the same snippet of code could have both '\n' and newl used together.
Beyond these are the performance concerns of course; that is that people may tend to use:
"My first line" << newl <<
"My second line";
rather than the more efficient and arguably more readable:
"My first line" "\n"
"My second line";
> 2. IIUC the difference between a character and a manipulator is that
> the manipulator is not tied to the streams character type. So for some
> applications '\n' does not suffice. To me stream.widen('\n') is
> sufficiently ugly to justify a newl modifier.
Could you elaborate here? I'm not up to speed enough to know where '\n' wouldn't get widened automatically. I agree that stream.widen('\n') is indeed ugly.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk