From: girod@tele.nokia.fi (Marc Girod)
Subject: Initialization of nonlocal static objects
Reply-To: marc.girod@ntc.nokia.com
Organization: kpd
Distribution: comp
Date: Wed, 16 Dec 1992 08:46:23 GMT

Hello everybody!

Abstract:

[ARM], 3.4 p 19: "Such initializations [nonlocal static objects] may
be done before the first statement of main() or deferred to any point
in time before the first use of a function or object defined in that
translation unit".

In the case described here (below), I would not need anything else but
that initialisation of nonlocal static objects would be carried before
the first statement of main(), and think that I have good reasons not
to want to use any function or object of the translation unit
explicitly priorily (this would defeat my whole purpose!).

My experience is that g++ does defer the initialisation, while HP CC
v3.0 seems not to. Are there strong arguments in favour of this freedom
to implementors, or shouldn't this rule be tightened up, in better
conformance with C?


Detailed description of the case:

I have two teams of people, the ones providing with a "system", the
others with "applications" to run on it.

The system will receive messages as untyped data from external
processes. The messages have a header though, containing a type id.
Internal events of suitable type should be constructed from the
messages (one message, one event).

This is thus a typical "virtual constructor" problem, and the solution
I am working on is the following: in the "interface object" dealing
with external messages, there is a table of pointers to static
objects, one for every event type, which know how to build an event
out of a message (again, for a given type only).

How to build this? Well, here are the classes:

- A base Event class.

- Event classes defined so far: Event1, Event2, Event'n', derived from
  Event.

- A base class EvEx (for Event Exemplar, terminology from [Coplien92])
  with as a static member exColl, the table of EvEx*, initialised with
  all the entries pointing to a default (static too) EvEx, dealing
  with unregistered event types.

- In every class Event'p', a nested class Ev'p'Ex, derived from EvEx,
  and a static member of this class (member of class Event'p' since
  nested classes may not have static data!). The constructor of
  Ev'p'Ex will add a copy of the 'this' pointer to exColl (already
  initialised, since defined in the base class).

This way, I thought that if somebody from the "applications" team
would like to add an event type, say 'n+1', he would have to provide
only a new class Event'n+1' (with its nested class and static member
ev'n+1'Ex) and to modify some objects to be suitable as destinations
for events of this new type, but HE WOULDN'T HAVE TO TOUCH ANY OF THE
"SYSTEM" FILES...

This unfortunately fails because the static members are not guarantied
to be initialised before main() is called.

Thanks for replies, and help on how to decently turn the problem!


[Coplien92]: Advanced C++ - Programming styles and idioms
             James O. Coplien
             Addison-Wesley 1992

[ARM]:       The Annotated C++ Reference Manual
             Margaret Ellis and Bjarne Stroustrup
             Addison-Wesley 1990
--
+-----------------------------------------------------------------------------+
| Marc Girod - Nokia Telecommunications       Phone: +358-0-511 7703          |
| TL4E - P.O. Box 12                            Fax: +358-0-511 7432          |
| SF-02611 Espoo 61 - Finland              Internet: marc.girod@ntc.nokia.com |
|    X.400: C=FI, A=Elisa, P=Nokia Telecom, UNIT=TRS, SUR=Girod, GIV=Marc     |
+-----------------------------------------------------------------------------+
Newsgroups: comp.std.c++