In article <4q9ll0$kd8@engnews1.Eng.Sun.COM> clamage@Eng.Sun.COM (Steve
Clamage) writes:

    [...]
|> Dynamically-linked libraries constitute potentially a pure extension to
|> C++, and it is up to the implementor to define syntax and semantics
|> for them.

Finally...

If this is so, would it be to much to ask that the standard require all
non-local statics to be initialized before main is called?  The
classical reason I hear for not requiring this is DLL's.  If behavior
when DLL's are involved is -- from the point of view of the standard --
undefined (and I have long felt that it is, or should be), then this
argument doesn't hold water.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <KANZE.96Jun21200808@slsvgqt.lts.sel.alcatel.de>,
kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:
> If this is so, would it be to much to ask that the standard require all
> non-local statics to be initialized before main is called?  The
> classical reason I hear for not requiring this is DLL's.  If behavior
> when DLL's are involved is -- from the point of view of the standard --
> undefined (and I have long felt that it is, or should be), then this
> argument doesn't hold water.

I think if the behavior of DLLs is undefined, then it won't be long before
a large majority of C++ programs have undefined semantics, so what's the
point of the standard?  DLLs provide a big space advantage, plus a large
performance advantage on multi-user systems.  (Strictly speaking, you don't
need a multi-user system, just a system on which more than one application
is running at a time.  That's true of just about every system nowadays,
even PCs.)

I understand that the standard cannot say anything about how a DLL is
created, but the wording about local static variables seems (to me) to say
that an implementor cannot possibly implement DLLs in such a way as to
conform to the standard.

--
Bill Leonard
Harris Computer Systems Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
Bill.Leonard@mail.hcsc.com

These opinions and statements are my own and do not necessarily reflect the
opinions or positions of Harris Computer Systems Corporation.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4qm5qs$2co@ns.hcsc.com> bill@amber.ssd.hcsc.com (Bill
Leonard) writes:

|> In article <KANZE.96Jun21200808@slsvgqt.lts.sel.alcatel.de>,
|> kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:
|> > If this is so, would it be to much to ask that the standard require all
|> > non-local statics to be initialized before main is called?  The
|> > classical reason I hear for not requiring this is DLL's.  If behavior
|> > when DLL's are involved is -- from the point of view of the standard --
|> > undefined (and I have long felt that it is, or should be), then this
|> > argument doesn't hold water.

|> I think if the behavior of DLLs is undefined, then it won't be long before
|> a large majority of C++ programs have undefined semantics, so what's the
|> point of the standard?

The standard doesn't define what a file is, or talk about keyboards or
screens or windowing systems.  Any program which does IO (or uses
floating point) has undefined semantics, at least from the point of
view of the standard.  While we all pretty much understand what we mean
when we say "writing to a file", the strict definition is furnished by
the implementation, and does vary from one implementation to another.
(Suppose that the file's name is "/dev/null", for example, under Unix.)

|> DLLs provide a big space advantage, plus a large
|> performance advantage on multi-user systems.  (Strictly speaking, you don't
|> need a multi-user system, just a system on which more than one application
|> is running at a time.  That's true of just about every system nowadays,
|> even PCs.)

|> I understand that the standard cannot say anything about how a DLL is
|> created, but the wording about local static variables seems (to me) to say
|> that an implementor cannot possibly implement DLLs in such a way as to
|> conform to the standard.

I believe that this is true, or should be so.  Ideally, perhaps, given
the widespread existence of DLL's, the standard should take them into
account, adding special wording to cover dynamic linking (both loading
and unloading) in the phases of compilation, as well as lifetime of
temporaries, variable and function linkage, etc.  I don't think that
there is any possibility of that this time around, and I don't think
that at present, we really know what the special wording should say.
(There are some potentially interesting interactions between DLL's and
the one definition rule, for example.)

IMHO, it is absolutly imperative that the standard guarantee the
existance of static variables between their creation and the calling of
exit.  I personally think that their existance should be guaranteed
before entering main; this is not the current state of the draft, but
is the case in all implementations (baring DLL's), and I am sure that
an implementation which doesn't do so will break a considerable lot of
existing code.

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article 2c2@ns.hcsc.com, bill@amber.ssd.hcsc.com (Bill Leonard) writes:
>
>Well, it sort of answers my question, but it raises some others.  Here is
>what I think this means:
>
>  * A good way to arrange for the destruction of local statics is to use
>    "atexit" (but see below).
>
>  * If you *don't* use atexit to arrange for destruction, whatever you
>    use had better work exactly as though you had.
>
>Now here's the problem: The C standard (and, by inclusion, the C++
>standard) only guarantees that you can register 32 functions with atexit.
>So how can a C++ implementation, particularly one based on a C
>implementation, use atexit for local static destruction without intruding
>on this limit?

I'll repeat the important part of what I quoted before:

"3.6.3 Termination [basic.start.term]

"1: Destructors (12.4) for initialized objects of static storage duration
(declared at block scope or at namespace scope) are called when returning
from main and when calling exit (18.3). These objects are destroyed in the
reverse order of the completion of their constructors. For an object of
array or class type, all subobjects of that object are destroyed before
any local object with static storage duration initialized during the
construction of the subobjects is destroyed."

Local static objects have block scope, and so are automatically
destroyed in the reverse order of their construction if the program
returns from main or calls exit.

The rest of the section dealt with local statics in functions called
via atexit. Those rules are complicated enough that you are
probably better off not having local static objects in a function
that is registered with atexit. Then you don't have to do anything
special to get local statics destroyed in reverse order of
construction -- the compiler does it for you.

The only other cases would be
- you want local statics destroyed if the program terminates other
than by returning from main or calling exit.
- you want local statics destroyed in some other order.

Those special cases are much harder to deal with, since you
have to be sure that objects are not destroyed twice even if
the program terminates normally. Once again, it would be better
to avoid having to deal with those special cases.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article 2c2@ns.hcsc.com, bill@amber.ssd.hcsc.com (Bill Leonard) writes:
>
>Another question this raises concerns implementations that provide
>dynamically-linked libraries.  Some such implementations allow libraries to
>be loaded and unloaded during execution of the program.  The standard seems
>to preclude such a library from containing a C++ function with a local
>static object, because it would have to destroy the local object after the
>library has ceased to be a part of the program.
>
>I fully realize that the standard does not (and cannot) talk about things
>like dynamically-linked libraries.  However, it should not preclude their
>existence nor drastically limit their capability.

The standard does not address dynamically-linked libraries at all.

"Static" objects in such libraries have lifetimes different from static
objects (or any other kind of objects) as defined by the standard, and
so are not static objects within the meaning of the standard. The order
of their construction and destruction is thus unspecified in the sense
of not being mentioned.

Dynamically-linked libraries constitute potentially a pure extension to
C++, and it is up to the implementor to define syntax and semantics
for them.

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]