In article <1994Jan4.030803.21404@csrd.uiuc.edu> harrison@sp10.csrd.uiuc.edu (Luddy Harrison) writes:
>Doesn't this open up a can of worms?

In a word, yes.

>Is this an acceptable state of affairs?

As usual, it probably depends upon whom you ask.

>... I find it a bit confusing
>to think of the semantics of a compilation unit varying according to whether
>it is dynamically linked, and according to whether other compilation units
>to which it refers are dynamically linked also.

Well, confusing or not, you had best get use to it if you plan to continue
writing C++ code (and compiling it into shared libraries).

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <2g7imp$524@news.delphi.com>, bobkf@news.delphi.com (BOBKF@DELPHI.COM) writes:
> According to ARM, initialization of nonlocal static objects can be
> "deferred to any point in time before the first use of a function
> or object defined in that translation unit."

Some time ago, I asked about this on this newsgroup---specifically, I
asked who had implemented this rule.  The question was mischievous, of
course.  I had been involved with Ada standardization, which (over a
decade ago) had faced exactly this issue.  The draft reference manual
had included essentially this rule, and we had raised essentially the
same issues as responders to my message did.  Our committee eventually
settled on a simple, but not entirely satisfactory solution---a pragma
that imposed additional elaboration-order constraints on
separately-compiled program modules.

My question to this group (straight this time) is can anyone tell me
of what revisions have been proposed or are being considered for
modifying this section of the ARM?  Thank you.

P. Hilfinger

hilfingr@tully.CS.Berkeley.EDU (Paul N. Hilfinger) writes:

>In article <2g7imp$524@news.delphi.com>, bobkf@news.delphi.com (BOBKF@DELPHI.COM) writes:
>> According to ARM, initialization of nonlocal static objects can be
>> "deferred to any point in time before the first use of a function
>> or object defined in that translation unit."

>My question to this group (straight this time) is can anyone tell me
>of what revisions have been proposed or are being considered for
>modifying this section of the ARM?  Thank you.

>P. Hilfinger

I've a related question: why not require that all
static objects be initialized before control enters main()?

In article <1994Jan3.115632.8420@csrd.uiuc.edu>, harrison@sp10.csrd.uiuc.edu (Luddy Harrison) writes:
|> hilfingr@tully.CS.Berkeley.EDU (Paul N. Hilfinger) writes:
|>
|> >In article <2g7imp$524@news.delphi.com>, bobkf@news.delphi.com (BOBKF@DELPHI.COM) writes:
|> >> According to ARM, initialization of nonlocal static objects can be
|> >> "deferred to any point in time before the first use of a function
|> >> or object defined in that translation unit."
|>
|> >My question to this group (straight this time) is can anyone tell me
|> >of what revisions have been proposed or are being considered for
|> >modifying this section of the ARM?  Thank you.
|>
|> >P. Hilfinger
|>
|> I've a related question: why not require that all
|> static objects be initialized before control enters main()?

There is a much more troubling issue, the one given on the Subject:
has the ANSI committee made any progress on solving the lack of
order in static initialization problem?  Yes this enters in to
issues of language design rather than standardization, but we already
have compilers with #pragma for this: will that be the solution?
How about a standard #pragma....    ;)

--
John.

John J. Barton        jjb@watson.ibm.com            (914)784-6645
H1-C13 IBM Watson Research Center P.O. Box 704 Hawthorne NY 10598

In article <2g7kfc$6r6@agate.berkeley.edu>,
Paul N. Hilfinger <hilfinger@CS.Berkeley.EDU> wrote:
...
>My question to this group (straight this time) is can anyone tell me
>of what revisions have been proposed or are being considered for
>modifying this section of the ARM?  Thank you.

There are a few different proposals under development, one by me, one (or two?)
by John Max Skaller, and possibly some others.  My proposal allows for full
automation at the possible expense of excessive false dependencies (though
it appears feasible to limit false dependencies.)  Skaller's is more similar
to the Ada approach.

Actually, the current incarnation of my approached eveolved from an attempt
to emulate the Ada approach.  The main problem with C++ as opposed to Ada
is that there really is no concept of a module, so it becomes difficult to
force ordering between what we might think of as modules.  There is no generic
way to specify the name of a compilation unit, meaning a compilation unit
ordering scheme also has to provide some way to name compilation units (which
introduces a whole new set of namespace problems.)  I believe Skaller is
proposing something to allow ordering based on namespaces, but I'm not
sure how he plans to handle fragmented namespace definitions.

I had at one point planned to provide a way to manually specify dependencies
between classes and objects, but by the time I added sufficient mechanism
to specify all the needed types of dependencies, I ended up with something
which could better be handled by fully automating dependency generation.

- Brad
--------------------------------------------------------------------------
+ Brad Daniels                  | Until you can prove unequivocally that +
+ Biles and Associates          | you're arguing epistemology with me,   +
+ These are my views, not B&A's | I won't argue epistemology with you.   +
--------------------------------------------------------------------------

In article <2g7imp$524@news.delphi.com>, bobkf@news.delphi.com
(BOBKF@DELPHI.COM) writes:
>>> According to ARM, initialization of nonlocal static objects can be
>>> "deferred to any point in time before the first use of a function
>>> or object defined in that translation unit."

hilfingr@tully.CS.Berkeley.EDU (Paul N. Hilfinger) writes:
>>My question to this group (straight this time) is can anyone tell me
>>of what revisions have been proposed or are being considered for
>>modifying this section of the ARM?  Thank you.

harrison@sp10.csrd.uiuc.edu (Luddy Harrison) writes:
>I've a related question: why not require that all
>static objects be initialized before control enters main()?

Consider shared libraries.  We might wish to avoid loading the library
until some part of it is actually used.  Some programs use methods like
"dlopen" (SunOS, other OSes call this something else) to permit the
program to link itself to a shared library at runtime.  It seems
appropriate in such cases to have the global constructors called at
the time the shared library is dynamically linked to, and the global
destructors can then be called when the library is "unmapped".

Consider very large programs in which calls to global constructors might page
in lots of code.  It seems desirable to postpone the invocation of some
constructors in cases where locality of reference is improved, provided
that no user-visible difference occurs.

I believe that the ARM rule was an attempt to accomodate this.  The exact
wording of the rule seems impossible to comply with, but it would be
undesirable to "fix" this in a way that makes things worse.



--
-- Joe Buck jbuck@synopsys.com
Posting from but not speaking for Synopsys, Inc.
Formerly jbuck@<various-hosts>.eecs.berkeley.edu

jbuck@synopsys.com (Joe Buck) writes:

>Consider shared libraries.  We might wish ...
> ... in such cases to have the global constructors called at
>the time the shared library is dynamically linked to, and the global
>destructors can then be called when the library is "unmapped".

Doesn't this open up a can of worms?  I assume that static
objects have to be destroyed in reverse order of their construction.
Now, imagine a class A with a constructor A() that calls a function F()
that is in a dynamically linked library.  Suppose that the object file
that contains F() also has a static object b that requires construction.
When I write "static A a;" I will cause A() to run, which will cause
the library containing F() to be mapped, and therefore (I presume) the
constructor of b to be invoked.  This means that the constructor of one
static object (a in this case) will "call" the constructor of another
(b in this case).  Put another way, the constructors of two static objects
will be active simultaneously.  Is this an acceptable state of affairs?
In what order would the destructors be called?  I find it a bit confusing
to think of the semantics of a compilation unit varying according to whether
it is dynamically linked, and according to whether other compilation units
to which it refers are dynamically linked also.

-Luddy Harrison

> From: jjb@watson.ibm.com (John Barton)
> Subject: Re: Order of static initialization?
> has the ANSI committee made any progress on solving the lack of
> order in static initialization problem?  Yes this enters in to

All previous ideas to solve this problem have serious flaws; so the committee
has been waiting for a reasonable solution to appear.

I have recently proposed such a solution, and it seems to be gaining
some support.  The idea is to initialize in 3 phases: phase 1
initializes all non-class objects with no initializers, or constant
initializers; phase 2 initializes all classes; phase 3 initializes
all other variables from top to bottom in a translation unit, in any
order.  To initialize a class I propose adding class constructors and
class destructors, and providing rules that cause these constructors
to be called in a sensible order.

The bottom line is that most all cases can be handled, and most
impossible cases can be caught.

-steve

********************************************************
* Steven Kearns, Ph.D.     ....uunet!softrue!kearns    *
* Software Truth           softrue%kearns@uunet.uu.net *
********************************************************

In article <CJ2B4K.16Gx@hawnews.watson.ibm.com> jjb@watson.ibm.com (John Barton) writes:
>
>There is a much more troubling issue, the one given on the Subject:
>has the ANSI committee made any progress on solving the lack of
>order in static initialization problem?  Yes this enters in to
>issues of language design rather than standardization, but we already
>have compilers with #pragma for this: will that be the solution?
>How about a standard #pragma....    ;)

 my solution is:

 module A {  stuff here }
 module B depends on A { more stuff }
 module C depends on X;

A "module" is a named translation unit.
(Probably it would be better to suggest:

 translation_unit A { .. }

but my fingers trip over the keys :-)

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <CJ2Ay4.I6C@biles.com> daniels@biles.com (Brad Daniels) writes:
>In article <2g7kfc$6r6@agate.berkeley.edu>,

>introduces a whole new set of namespace problems.)  I believe Skaller is
>proposing something to allow ordering based on namespaces, but I'm not
>sure how he plans to handle fragmented namespace definitions.

 Basically, I dont think it can work. But I'm not sure.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <38.UUL1.3#8618@softrue.UUCP> kearns@softrue.UUCP (Steven Kearns) writes:
>> From: jjb@watson.ibm.com (John Barton)
>> Subject: Re: Order of static initialization?
>> has the ANSI committee made any progress on solving the lack of
>> order in static initialization problem?  Yes this enters in to
>
>All previous ideas to solve this problem have serious flaws; so the committee
>has been waiting for a reasonable solution to appear.
>
>I have recently proposed such a solution, and it seems to be gaining
>some support.  The idea is to initialize in 3 phases: phase 1
>initializes all non-class objects with no initializers, or constant
>initializers; phase 2 initializes all classes; phase 3 initializes
>all other variables from top to bottom in a translation unit, in any
>order.  To initialize a class I propose adding class constructors and
>class destructors, and providing rules that cause these constructors
>to be called in a sensible order.
>
>The bottom line is that most all cases can be handled, and most
>impossible cases can be caught.

 The nice thing about Steve's proposal is that Brads
can be used in conjunction with it, and the programmer
can reduce the work required of the compiler/linker by
Brads approach by moving variables into classes, utilising
Steve's class constructors. Brads approach can then be used
again within each class.

 So the combination allows manual control
at the class level to factor the big problem into
smaller ones: offering both manual and automatic
ordering.

 The cost is a signiciant language extension,
but one for which there is existing experience in
other languages.


--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

>>>>> On Mon, 3 Jan 1994 22:16:37 GMT, jbuck@synopsys.com (Joe Buck) said:

Joe> Consider shared libraries.  We might wish to avoid loading the
Joe> library until some part of it is actually used.  Some programs
Joe> use methods like "dlopen" (SunOS, other OSes call this something
Joe> else) to permit the program to link itself to a shared library at
Joe> runtime.  It seems appropriate in such cases to have the global
Joe> constructors called at the time the shared library is dynamically
Joe> linked to, and the global destructors can then be called when the
Joe> library is "unmapped".

Joe> Consider very large programs in which calls to global
Joe> constructors might page in lots of code.  It seems desirable to
Joe> postpone the invocation of some constructors in cases where
Joe> locality of reference is improved, provided that no user-visible
Joe> difference occurs.

If this deferred linking were mandatory, it basically means that you
could not do real-time programming in C++. I must admit, however, I
would have loved this sort of thing 15 years ago when I was working
with overlays on a PDP 11. It's nice to know that some skills never
become obsolete.

Unfortunately, these proposals don't really seem to address what is
the biggest concern to me, control of side effects in initializers.
If, for example, my objects are controlling devices, the order of
initialization and destruction may matter a great deal. The current
state of things makes object oriented control of devices somewhat
awkward (at best).

 Hayden


--
Hayden Schultz
haydens@ll.mit.edu
MIT Lincoln Lab
244 Wood St.
Lexington, MA, 02173
(617) 981-3685