cout unbuffered in Standard?
Paul
http://www.aristeia.com/magazines.html
and the article 'The little endl that couldn't' by Scott Meyers.
In it he notes that in the current Standard makes cout unbuffered by default.
Is this true? If so, doesn't this make a LOT of existing code suddenly
inefficient as the implementations catch up with the standard?
--
------
Paul Scott <pms...@dera.gov.uk>
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Francis Glassborow
<pa...@toilet.dera.gov.uk> writes
>In it he notes that in the current Standard makes cout unbuffered by default.
>Is this true? If so, doesn't this make a LOT of existing code suddenly
>inefficient as the implementations catch up with the standard?
No, he made a mistake if that is what he wrote.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Andrew Koenig
Paul <pa...@toilet.dera.gov.uk> wrote:
>and the article 'The little endl that couldn't' by Scott Meyers.
>In it he notes that in the current Standard makes cout unbuffered by default.
>Is this true? If so, doesn't this make a LOT of existing code suddenly
>inefficient as the implementations catch up with the standard?
A quick check of the standard suggests that cerr is unbuffered by default
and cout and clog are buffered. I did *not* do a detailed search, so
if someone else can find a citation in the standard that states otherwise,
I'd appreciate knowing about it.
--
Andrew Koenig, a...@research.att.com, http://www.research.att.com/info/ark
Darin Adler
> In the thread on '\n' or endl, I was pointed to
>
> http://www.aristeia.com/magazines.html
>
> and the article 'The little endl that couldn't' by Scott Meyers.
>
> In it he notes that in the current Standard makes cout unbuffered by default.
> Is this true? If so, doesn't this make a LOT of existing code suddenly
> inefficient as the implementations catch up with the standard?
The article doesn't match the standard. The standard requires cerr to be
unbuffered, but doesn't require that for cout.
Both Bjarne and I posted responses saying this in the original thread.
-- Darin
Dietmar Kuehl
In article <slrn7vm8s...@toilet.dera.gov.uk>,
pa...@toilet.dera.gov.uk (Paul) wrote:
> In it he notes that in the current Standard makes cout unbuffered by
> default.
> Is this true? If so, doesn't this make a LOT of existing code suddenly
> inefficient as the implementations catch up with the standard?
The standard does not require that 'cout' is unbuffered. There is,
however, a chance that 'cout' is indeed kind of unbuffered: To
synchronize with 'stdout' as required by the standard 'cout' is likely
to be unbuffered itself, handing characters over to 'stdout' as soon as
they are received. This is, of course, not required because it is
possible to implement stdio and iostreams in a cooperative way (eg. by
having 'FILE' being identical to 'streambuf'; well, not exactly but in
some sense this is about it) where both 'stdout' and 'cout' are
buffered. I'm not aware of any implementation doing this.
In any case, if you turn off buffering (see 'sync_with_stdio()') it is
likely that 'cout' is buffered unless 'sync_with_stdio()' actually has
no effect.
--
<mailto:dietma...@claas-solutions.de>
homepage: <http://www.informatik.uni-konstanz.de/~kuehl>
Sent via Deja.com http://www.deja.com/
Before you buy.
Dietmar Kuehl
In article <FJ76...@research.att.com>,
a...@research.att.com (Andrew Koenig) wrote:
> A quick check of the standard suggests that cerr is unbuffered by
default
> and cout and clog are buffered. I did *not* do a detailed search, so
> if someone else can find a citation in the standard that states
> otherwise, I'd appreciate knowing about it.
The standard does not mandate much for 'cout'. It says that it goes to
same destination where 'stdout' goes and that 'cout' is synchronized
with 'stdout' as is the default and can be changed with
'sync_with_stdio()'. There is nothing specified about 'cout' with
respect to the stream buffer used and whether this stream buffer uses
buffering. Thus, an unbuffered 'cout' is definitely within the limits of
the standard.
What does it mean for 'cout' to be buffered anyway? There are two
obvious definitions:
- Output is written using the corresponding system calls only for chunks
of characters. That is, buffering with respect to system calls.
- The stream buffer's put area is non-empty, that is, 'overflow()' is
not called for each individually written character.
According to the second definition, 'cout' has a fair chance of being
unbuffered if synchronization is turned on: 'cout's stream buffer will
likely just forward the received characters to 'stdout' and never put
them into the stream buffer's buffer. This is the case if the C library
is used for both C and C++ programs and the C library is not implemented
in terms of the C++ library. This situation is a rather likely set up.
According to the first definition 'cout' is likely to be buffered:
Buffering is done in 'stdout'.
Christopher Eltschka
[...]
> they are received. This is, of course, not required because it is
> possible to implement stdio and iostreams in a cooperative way (eg. by
> having 'FILE' being identical to 'streambuf'; well, not exactly but in
> some sense this is about it) where both 'stdout' and 'cout' are
> buffered. I'm not aware of any implementation doing this.
>From the GNU iostream info file:
----8<--------8<--------8<----
File: iostream.info, Node: stdio - C-style input/output, Next:
Streambuf internals, Prev: Using the streambuf layer, Up: Top
[...]
Extensions beyond ANSI:
* A stdio FILE is identical to a streambuf. Hence there is no need
to worry about synchronizing C and C++ input/output - they are by
definition always synchronized.
* If you create a new streambuf sub-class (in C++), you can use it
as a FILE from C. Thus the system is extensible using the standard
streambuf protocol.
[...]
----8<--------8<--------8<----
As you see, you can even remove the "not exactly" part ;-)
[...]