From: Daryle Walker (darylew_at_[hidden])
Date: 2004-08-28 03:13:44
On 8/27/04 6:43 PM, "Jonathan Turkanis" <technews_at_[hidden]> wrote:
> "Rob Stewart" <stewart_at_[hidden]> wrote in message:
>> From: "Jonathan Turkanis" <technews_at_[hidden]>
>>> "Rob Stewart" <stewart_at_[hidden]> wrote in message
>>> 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,
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
-- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk