In article <KANZE.95Dec11155728@slsvewt.lts.sel.alcatel.de>
kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:

> (The current public draft is singularly silent on the
> question of when, or even if, the predefined streams are flushed.  It
> does state that the stream objects are never destructed, which would
> mean that they are probably never closed.)

There is a description of a class called ios_base::Init with a static
integer member called init_cnt. The April 28 draft says (27.4.3.1.6,
[lib.ios::Init])

Init();
 Effects: Constructs an object of class Init. If init_cnt is zero,
the function stores the value one in init_cnt, then constructs and
initializes the objects cin, cout, cerr, clog (27.3.1), win, wout, werr
and wlog (27.3.2). In any case, the function then adds one to the value
stored in init_cnt.

~Init();
 Effects: Destroys an object of class Init. The function subtracts
one from the value stored in init_cnt and, if the resulting stored value
is one, calls cout.flush(), cerr.flush(), and clog.flush().

IMHO there are many things missings here, and I don't know if they have
been fixed in later releases of the draft.

Firstly, I haven't been able to find a header file that declares a static
object of class ios_base::Init - I would expect that to be in <iostream>.
27.3 [lib.iostream.objects] says that [cw]in [cw]out, [cw]err and [cw]log
are initialized the first time an object of a class called
basic_ios<charT, traits>::Init is constructed, but I couldn't find any
further reference to that class. Since the basic_ios template inherits
from ios_base, I'm assuming ios_base::Init is meant here.

Secondly, it seems that wout, werr and wlog are not flushed when
ios_base::Init::init_cnt drops back to one.

Finally, since class ios_base::Init will have a compiler-generated copy
constructor doing nothing, it's very easy to force a premature flush by
simply copy-constructing an temporary object of that class.

Am I missing something? Does anyone know if the issues I mention here have
been fixed in a subsequent draft release?

- Wil Evers (wil@ittpub.nl)


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]