Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!mcvax!hp4nl!philapd!ssp1!roelof
From: roelof@idca.tds.PHILIPS.nl (R. Vuurboom)
Newsgroups: comp.lang.c++
Subject: Re: munch
Summary: No such thing as a free munch?
Keywords: static objects / construction order
Message-ID: <218@ssp1.idca.tds.philips.nl>
Date: 31 Jul 89 15:50:29 GMT
References: <24096@genrad.UUCP> <9698@alice.UUCP>
Organization: Philips Telecommunication and Data Systems, The Netherlands
Lines: 53

In article <9698@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes:
>In article <24096@genrad.UUCP>, dxb@genrad.com (Daniel A. Burkhard) writes:
>
>> I need some way to control the order of construction
>> of static objects.
>
>I and others have thought for some time about doing it
>and have yet to come up with a way of specifying the
>order that is (a) useful, (b) consistent, and (c) not
>too hard to implement.  Let me know if you find one.
>-- 

I know I've got to be missing something here but am curious to find out.
A (at least to me) "obvious" solution comes to mind so I'm wondering
which of the above (a,b,c) it must be breaking (or whether I understand
the problem properly).

Assumedly, you'ld want control over (1) construction order of static objects
in the same file and control over (2) construction order of (groups of) statics
in different files. 

For (1) allow extern declarations (used as forward references) to determine 
construction order:

extern int you;
extern int me;

static int me;

f()
{
  static int you;
}

would specify that you is to be constructed before me.

For (2) order of linkage determines order of construction of the various 
groups of statics.

Consistency problems are obvious with (2) so how far would specifying
(1) alone get you if unacceptable? 

Note,by the way, that by asking the user to include as first header 
your header with forward references you could always override the 
ordering given by (2) (I think :-).

And (naturally) you've noted that the above technique(s) won't break
existing code (I hope) nor change existing semantics.
-- 
I don't know what the question means, but the answer is yes...
(overheard on comp.lang.misc)
Roelof Vuurboom  SSP/V3   Philips TDS Apeldoorn, The Netherlands   +31 55 432226
domain: roelof@idca.tds.philips.nl             uucp:  ...!mcvax!philapd!roelof