Re: Feedback needed, especially non-Linux

> > > Consider this program....
> > > ================
> > > #include <iostream>
> > > class foo {
> > > public:
> > >   foo() {std::cout << "Hello world\n";}
> > > } x;
> > >
> > > int main() {}
> > > ================
> >
> > Solution:
> >
> > If you need iostream facilities during global initialization
> > (pre-main), you can guarantee it is set up by inserting:
> >
> > static const std::ios_base::Init _init;
> >
> > before uses of std::cout, etc...
>
> Are you telling me that it doesn't?  Ahh. ... link order
> problem.  The language spec requires this to work.  It works
> for me.
>
> Is that Init_init documented anywhere, in the C++ standard
> document?  I did not see it in Stroustrup's book.  If not, it
> is not portable either, no improvement over the link order
> issue.  If I have 100 files like this, should I put that in all
> 100 of them?  It looks like a hack..

In my copy of TC++PL, 2nd Ed., Sec. 21.5.2: Closing of Streams (pp.
639-40) discusses the matter.  (Don't you love this book? :^D )

In the Standard, it's in sections [iostream.objects: 27.3?, ios.Init:
27.4.2.1.6?].  (I don't actually have a copy handy, just found mention of
in in Google, hope chapter numbers are right.)  Anyhow, it's not a hack,
it is "good design", I'm sure Bjarne himself would attest!

> > By the same token, it also makes sure the stream facilities
> > stay alive long enough during global destruction, (some
> > reference-count like mechanism) since destruction happens in
> > reverse order (within each translation unit).
>
> Destruction happens in reverse order, period.  That is, in
> reverse of the actual construction order.

I've witnessed at least one system where the order of translation unit
global destruction is *not* the reverse of the ordering chosen in
initialization.  :(  Nevertheless, using the ios_base::Init technique
should be robust to even the most nonsensical TU-orderings!

David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
	-- (2400 baud? Netscape 3.0?? lynx??? No problem!)