In article <1995Dec12.110202.1688@ittpub> wil@ittpub.nl (Wil Evers)
writes:

|> 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().

This will generally help, but I'm not sure that it is sufficient in
the general case.  If a destructor of a static object tries to use
cout, for example, what is the guarantee that there is still one
ios::Init object left to be destructed (and thus trigger the flush)?
I don't think that there is one.

Of course, if the cout usage is directly in the destructor, I would
probably just declare a local ios::Init in the destructor, to be on
the safe side (or just call cout.flush() directly).  The problem
occurs when the destructor calls another function which uses cout;
presumably, this function doesn't know that it will be called from a
destructor of a static object, and will probably not have taken any
precautions.

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone



---
[ 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. ]