🚀 go-pugleaf

Relay-Version: ANU News - V6.1B9 05/16/94 VAX/VMS; site ittpub
Newsgroups: comp.std.c++
Subject: Re: predefined streams flushed at exit? (Was: Re: Trouble running a  
Message-ID: <1995Dec14.155740.1698@ittpub>
From: wil@ittpub.nl (Wil Evers)
References: <9512131117.AA04138@lts.sel.alcatel.de>
Distribution: world
X-Nntp-Posting-Host: lintilla
Lines: 41
Approved: clamage@eng.sun.com (comp.std.c++)

In article <9512131117.AA04138@lts.sel.alcatel.de> James Kanze US/ESC  
60/3/141 #40763 <kanze@lts.sel.alcatel.de> writes:

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

I think the nifty_counter idiom as described in section 3.4 in the ARM  
should do the trick, although using it correctly is definitely  
non-trivial. 

Supposing the header <iostream> contains a definition of a static object  
of class ios_base::Init (BTW: I can't seem to find such an object in the  
DWP), then all objects defined lexically after an #include <iostream> will  
be destructed before the ios_base::Init object is destructed (DWP: 3.6.2  
[basic.start.init], 3.6.3 [basic.start.term]). 

This means that any translation unit that defines an object of a class X  
with a destructor writing to one of the predefined streams must directly  
or indirectly include <iostream>, which, in turn, implies that <iostream>  
must be a nested #include in X's header file, even if there is no further  
reference to anything from <iostream> in X's class definition.

I see two pitfalls here:

1. If an innocent programmer trying to reduce compilation time moves the  
#include <iostream> from X's header file to its implementation file, other  
translation units can define X objects that are possibly destructed after  
the predefined streams are flushed, but no compiler will ever detect this.

2. To establish whether or not X's header file needs a nested #include  
<iostream>, we will need to know whether or not any of the functions  
called from X's destructor write to the predefined streams. Again, if this  
ever changes, I don't think any compiler can detect this.

All in all, writing reliable destructors is definitely a tricky business.  
Any comments or suggestions?

- Wil

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