Re: [boost] Review of Daryle Walker's "More IO" library begins today, August 21, 2004.

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
>>> news:200408262114.i7QLEOP14442_at_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