On 8/27/04 6:43 PM, "Jonathan Turkanis" <technews@kangaroologic.com> wrote:
"Rob Stewart" <stewart@sig.com> wrote in message:
From: "Jonathan Turkanis" <technews@kangaroologic.com>
"Rob Stewart" <stewart@sig.com> wrote in message news:200408262114.i7QLEOP14442@lawrencewelk.systems.susq.com... [SNIP] The main benefit of newl (I think) is that it calls attention to a character which receives special treatment in some contexts. It can't achieve this purpose unless people know what it means. I wouldn't want someone examining my code to spend time looking through boost documentation only to find that the manipulator just writes a newline.
I don't think many would have a hard time recognizing the parallel between "newl" and "endl." If you rename it to "newline," there's no chance of misunderstanding the manipulator, right?
I know "new_line" or "newline" would be clearer, but "newl" happens to be the same length as typing in ['\n'] or ["\n"], four characters. If I change "skipl" to "skip_line", I should do the same to "newl" to be consistent.
Yes. I was too hasty in rejecting it. Even if it's called "newline", though, people may still wonder why it's being used instead of endl or "\n" and end up consulting the documentation.
As it happens, inserting "\n" is slower than using newl because of the formatted I/O logic of streams and because of the invocation of (in effect, at least) strlen().
My guess is that in typical cases this difference is miniscule. If this is an important part of the rationale, I'd like to see some performance data.
I use preincrement/predecrement unless I need the post* version so that my code is certain to be optimal. I create an end iterator outside of any loops that I may write so that the end() mf isn't evaluated each time through the loop. There are many things that I do out of habit that ensure that I'm writing the most efficient code I can before I profile to find algorithmic hotspots to address.
I do this stuff, too. The situation is different with library components, though. Imagine someone proposing a new container based on its performance characteristics but not presenting any performance data.
I think someone (Paul?) did a performance test during last year's review. I don't recall how it turned out.
At any rate, you and Reece have convinced me that my rejection of some of the manipulators was rash. I'm still not sure about ios_form; I'd like to hear Daryle's rationale.
I've read Stroustrup's C++ book (third edition) a lot. A lot of submission ideas come from examples in his book. The form class was one of them. I realized that packaging a set of formatting changes for later and/or repeated use could be helpful (e.g. tables).
BTW -- Daryle, where are you??? I'd like to hear your answers to some of my objections.
-- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com