Boost logo

Boost :

From: Paul A Bristow (pbristow_at_[hidden])
Date: 2004-10-12 12:46:49


| -----Original Message-----
| From: boost-bounces_at_[hidden]
| [mailto:boost-bounces_at_[hidden]] On Behalf Of Paul A Bristow
| Sent: 26 August 2004 15:47
| To: boost_at_[hidden]
| Subject: RE: [boost] Review of Daryle Walker's "More IO"
| library begins today,August 21, 2004.

I am aware it is too late for this review,
but I have recently been re-building some examples using MSVC 8.0, (with
mixed success)
and one of them is the newl function re-proposed by Daryle.

(I can't remember who originally proposed this function - but he was highly
reputable ;-)

To recap, there was some query on how useful this was.

>From a very naïve test of a lot of new lines, I can report:

1 MSVC 8.0 seems significantly faster (unless I have missed something).

2 A newline as /n or using newl costs twice as much as a normal alphachar -
because it does cr lf??

3 A C string "/n" takes only the same as a single char.

3 endl takes 10 times as long - for the flush?

4 These times are NOW the same for sending to files and to cout (previously
much slower to cout).

Obviously, one doesn't only send newlines, but I still believe one can
conclude:

A newl is conceptionally correct over endl - it doesn’t flush unncessarily.

B newl offers a slight performance advantage over endl.

C ensuring that your newlines are embedded/concatenated into C strings
where possible is best of all.

So writing

cout << "Line1" "/n" // concatentates. Is more to type but clearer?
        "Line2/n" // idle typists may prefer?
        "\n" "Line 3" // Not So clear?
        "Line 4" << newl // Clear but less efficient.
        << endl; // Only if a final flush is required.

is faster and clearer than:

cout << "Line1" << endl
     << "Line2" << endl ...
        
So I still believe that function newl is the Right Thing To Do.

Paul

Paul A Bristow
Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB
+44 1539 561830 +44 7714 330204
mailto: pbristow_at_[hidden]


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk