JTC1/SC22/WG21 N0717

                                   Doc No   : X3J16/95-0117 WG21/N0717
                                   Date     : 04.07.95
                                   Project  : Programmming Language C++
                                   Ref.Doc  : X3J16/95-0093 WG21/N0693
                                   Reply to : Manfred Lichtmannegger
                                              manfred.lichtmannegger@mch.sni.de
 
Title: Explicit initialization of globals before main
       ==============================================
 
Problem:
--------
 
To enforce early initialization of globals before main to guarantee
portability of the idiom "attach by initialization".
 
Discussion:
-----------
 
Chapter 3.6.2 Initialization of non-local objects states that the initialization
of nonlocal objects with static storage duration (3.7) can 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". This very liberal
statement makes a well known technique , based on the fact that most compiler
initialize before main, non portable.
 
This idiom attaches a class, a function, a method or an object to a "system" by
the "side effect" of initializing a global object. This technique allows to
link a "self organizing" program from a selection of (independent) building
blocks together. Such an extensible architecture seems to be important enough to
standardize its portability.
 
This idiom is used to add options and their interpreters to main (James Kanze),
to add services to an object request broker, to add derived classes to their
base classes to allow polymorphic search on class extents (in GINA *). It can be
used to add items and callbacks to a menu, events and event handlers to
XtMainLoop etc. .
 
(*) Generalized Interface for Networked Application (my own project)
 
Solution:
---------
 
As this idiom is not the only usage of globals the freedom to defer the
initialization of globals should be preserved. Therefore some syntactic sugar at
the definition of non local objects is necessary to explicitly enforce early
initialization of globals before main (in contrast to implicit initialization
before the first use of any function or object defined in that translation unit)
 
 // initialize class static data member before main
 explicit AttachClassToClassManager X::staticMember(args);
 
 // initialize file static object before main
 explicit static AttachModule fileStatic(args);
 
The explicit keyword is used as it is already a keyword in C++. Other candidates
are early, init etc. . As explicit is only used to declare constructors there
should be no principal syntax problem.
 
If a module contains one global with explicit initialization as consequence
of the rules in 3.6.2 all globals in this translation unit will be initialized
before main.
 
Classification:
--------------
 
The proposal just allows to enforce the initialization strategy most frequently
used by compilers, without loosing the freedom to defer initialization. The
proposal breaks no existing code but makes it possible to make existing code
more portable.
 
( I would classify it as a "must have" as the idiom "attach by initialization"
  - is there some better name for it - is important to build systems with a
  flexible extensible architecture from independent building blocks.)
 
Relations:
----------
 
Sharable libraries and dynamic linking are not mentioned in the draft but are
affected by the problem of initializations. Dynamic linking means that you can
decide at runtime, i.e. inside main, to link additional arbitrary modules.
Within these modules explicit initialization can only happen at dynamic link
time but and not before main (*).
 
A sharable library fixed before runtime (by ld) is just an optimization. The
library is a known part of the program. Of course the programmer can factor out
explicit initializations in normal libraries or modules ( may be with auxiliary
stubs to avoid direct access to the shared libraries during initialization ).
 
The proposal has no relation to the problem of dependencies among the
initializations of static objects. As there are programming techniques to handle
these dependencies among non local objects, it seems to be not a real problem.
 
There is no specific semantic for explicit initialization in templates. In many
cases explicit instantiation of a static data member in a class member would be
necessary.
 
Proposal:
---------
 
Add to 3.6.2 as 3. sentence:
----------------------------
 
 3.6.2  Initialization of non-local objects                  [basic.start.init]
 
 ...
 
 Nonlocal objects with static storage duration defined with the keyword explicit
 are initialized before the first statement of main() XX).
 
 XX) If they are part of a dynamically linked translation unit they are
     initialized at dynamic link time.
 
Add new chapter 7.1.6:
----------------------
 
Comment: Reusing explicit would move keyword explicit from function-specifier
to a separate chapter decl-specifier like friend (*). As a consequence paragraph
5 of 7.1.2 Function specifiers has to be extended and moved to the new chapter:
 
 7.1.6 The explicit specifier                                    [dcl.explicit]
 
 The explicit specifier shall be used only in declarations of constructors
 within a class declaration (12.3.1.) or in the definition of non local objects
 (3.6.2).
 
Add hint to chapter 9.5.2 to paragraph 5:
-----------------------------------------
 
 9.5.2  Static data members                                 [class.static.data]
 
 ...
 
 The definition of a static data member can use the specifier explicit
 (see 3.6.2.).
 
----
(*) In A.5 keyword explicit has to be moved from function-specifier to
    decl-specifier. In 7.1.2 keyword explicit have to be removed.
 
 
PS: To allow the specifier explicit only at the definition of a non local
    object and not at its declaration is only a matter of taste. It can be
    done the other way too.