In article <3r1qbo$2ic@gabi.gabi-soft.fr>, J. Kanze <kanze@gabi-soft.fr> wrote:
>
>So what's the point of using DLL's, then?
>
>From discussions with people implementing DLL's, they will only be
>loaded on demand.  In particular, large parts of a program may never be
>loaded.  (Admittedly, my discussions only concerned Unix DLL's.)


 Modularity. Programs built with DLL's can be upgraded
and extended in pieces.
--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

Peter Michalek (peterm@netmanage.com) wrote:

|> In Article<3pupe4$vr@gabi.gabi-soft.fr>, <kanze@gabi-soft.fr> write:

|> > I'm probably going out on a limb when I say this, but I suspect that
|> > none of the compilers which supports DLL's guarantees initialization of
|> > all static objects before main.

|> I think this is not true.
|> In a typical scenario on Windows:

|> app.exe links to mylib.dll.
|> At load time, app.exe is loaded. Before WinMain starts executing, mylib.dll is
|> loaded and initialized (Windows calls LibEntry function, DLLEntry on Win32).
|> According to the rule mentioned above, static initializers will be called
|> before LibEntry is called, and therefore before WinMain starts executing.

So what's the point of using DLL's, then?

In article <NEWTNews.802150085.15743.peterm@fatra.netmanage.com>,
   Peter Michalek <peterm@netmanage.com> wrote:
:
:I think this is not true.
:In a typical scenario on Windows:
:
:app.exe links to mylib.dll.
:At load time, app.exe is loaded. Before WinMain starts executing,
:mylib.dll is loaded and initialized (Windows calls LibEntry
:function, DLLEntry on Win32).  According to the rule mentioned
:above, static initializers will be called before LibEntry is
:called, and therefore before WinMain starts executing.
:
:It's easy to verify by doing outputdebug string to secondary
:monitor in static constructors on MS-Windows.

This is true if you let the link/rc phase insert the DLL loads for
you by use of an import library.  It's not true if you handle your
dynamic linking via the LoadLibrary call, which can let you specify
the DLL to load at runtime.



 --Paul J. Ste. Marie, pstemari@well.sf.ca.us, pstemari@erinet.com

The Financial Crimes Enforcement Network claims that they capture every
public posting that has their name ("FinCEN") in it.  I wish them good hunting.

In Article<3pupe4$vr@gabi.gabi-soft.fr>, <kanze@gabi-soft.fr> write:
> Path: interramp.com!psinntp!psinntp!gatech!howland.reston.ans.net!news.sprintlink.net!pipex!oleane!gabi-soft.fr!gabi-soft.fr!not-for-mail
> From: kanze@gabi-soft.fr (J. Kanze)
> Newsgroups: comp.std.c++
> Subject: Re: The C++ FAQ book, question #180
> Date: 24 May 1995 10:06:28 +0200
> Organization: GABI Software, Sarl.
> Lines: 48
> Distribution: world
> Message-ID: <3pupe4$vr@gabi.gabi-soft.fr>
> References: <HCOBB.95May20120237@cinder> <3ptc85$ij5@offas_dike.sbil.co.uk>
> NNTP-Posting-Host: gabi.gabi-soft.fr
> X-Newsreader: TIN [version 1.2 PL2]
>
> Marc Shepherd (shepherd@debussy.sbi.com) wrote:
> |> In article 95May20120237@cinder, hcobb@slip.net () writes:
> |> >
> |> >The C++ FAQs book, question number 180: (WRT file scope static
> |> >objects)"...Their constructors are invoked before main() begins
> |> >executing..."
> |> >
> |> >I used to believe this, and had a system where entire modules where
> |> >simply presented to the linker and bound in with the program (by having
> |> >a FSSO register itself with a singleton.)
>
> |> >
> |> >But I reread the ARM and noticed that the actual rule was "...is done
> |> >before the first use of any function or object defined in that
> |> >translation unit" (ARM: 3.4)
> |> >
> |> >This makes considerable sense, if you consider a program that only drags
> |> >a great deal of DLL objects in on rare executions. (Otherwise you pay
> |> >the startup cost of every "module" that might be invoked, at the start
> |> >of each run)
> |> >
>
> |> Notwithstanding the ARM rule, I believe most implementations actually
> |> do initialize all static objects before main begins execution.
>
> Although I've not run into the problem, I know from email with compiler
> implementors that this is not actually the case.  Initializing a static
> object in a DLL (.so in Unix-speak) would require loading the library on
> start-up, for example, which rather defeats the purpose of using DLL's.
>
> I'm probably going out on a limb when I say this, but I suspect that
> none of the compilers which supports DLL's guarantees initialization of
> all static objects before main.
>

I think this is not true.
In a typical scenario on Windows:

app.exe links to mylib.dll.
At load time, app.exe is loaded. Before WinMain starts executing, mylib.dll is
loaded and initialized (Windows calls LibEntry function, DLLEntry on Win32).
According to the rule mentioned above, static initializers will be called
before LibEntry is called, and therefore before WinMain starts executing.

It's easy to verify by doing outputdebug string to secondary monitor in static
constructors on MS-Windows.




> |> Consider
> |> the consequences if it didn't work this way.  The compiler would have to
> |> put run-time checks into every function, checking whether the necessary
> |> initializations for that function's original translation unit had been
> |> performed yet.  (The checks could be omitted for functions defined in a
> |> translation unit that had no global variables requiring initialization.)
>
> Again, just speculation, but I suspect that the general strategy is to
> perform the initializations when the (DDL containing the) static object
> is loaded.
> --
> James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
> GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
> Conseils en informatique industrielle--
>                              --Beratung in industrieller Datenverarbeitung

Peter

Marc Shepherd (shepherd@debussy.sbi.com) wrote:
|> In article 95May20120237@cinder, hcobb@slip.net () writes:
|> >
|> >The C++ FAQs book, question number 180: (WRT file scope static
|> >objects)"...Their constructors are invoked before main() begins
|> >executing..."
|> >
|> >I used to believe this, and had a system where entire modules where
|> >simply presented to the linker and bound in with the program (by having
|> >a FSSO register itself with a singleton.)
|> >
|> >But I reread the ARM and noticed that the actual rule was "...is done
|> >before the first use of any function or object defined in that
|> >translation unit" (ARM: 3.4)
|> >
|> >This makes considerable sense, if you consider a program that only drags
|> >a great deal of DLL objects in on rare executions. (Otherwise you pay
|> >the startup cost of every "module" that might be invoked, at the start
|> >of each run)
|> >

|> Notwithstanding the ARM rule, I believe most implementations actually
|> do initialize all static objects before main begins execution.

Although I've not run into the problem, I know from email with compiler
implementors that this is not actually the case.  Initializing a static
object in a DLL (.so in Unix-speak) would require loading the library on
start-up, for example, which rather defeats the purpose of using DLL's.

I'm probably going out on a limb when I say this, but I suspect that
none of the compilers which supports DLL's guarantees initialization of
all static objects before main.

|> Consider
|> the consequences if it didn't work this way.  The compiler would have to
|> put run-time checks into every function, checking whether the necessary
|> initializations for that function's original translation unit had been
|> performed yet.  (The checks could be omitted for functions defined in a
|> translation unit that had no global variables requiring initialization.)

Again, just speculation, but I suspect that the general strategy is to
perform the initializations when the (DDL containing the) static object
is loaded.
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung

shepherd@debussy.sbi.com (Marc Shepherd) wrote:
[snip]
>Ideally, I suppose one would like to have a finer-grained control over
>when global objects are initialized.  I understand the standards-writers
>wrestled with this for a while, but could not devise a sensible syntax
>for it--so the timing of such initializations was left unspecified (other
>than a few minimal guarantees).

Was it only a syntax problem ?
Is there some records of the discussions about this subject ? I'm  very
interested by the proposed solutions, why they were not adopted, etc.

--- Raoul De Kezel

In article <3ptc85$ij5@offas_dike.sbil.co.uk>,
Marc Shepherd <shepherd@debussy.sbi.com> wrote:

> Notwithstanding the ARM rule, I believe most implementations actually
> do initialize all static objects before main begins execution.  Consider
> the consequences if it didn't work this way.  The compiler would have to
> put run-time checks into every function, checking whether the necessary
> initializations for that function's original translation unit had been
> performed yet.

But this reasoning falls apart in the presence of dynamically-linked
libraries.  (The original poster alluded to this.)  Typically, the
static objects in such a library do not even get loaded until the first
call to a function in that library.  At that point (again, I'm just
speaking of typical behavior), all of the static objects in that
particular library get initialized.

The initialization is not triggered by run-time checks in every function.
It happens as a side-effect of the library being loaded.
--
   John Polstra                                       jdp@polstra.com
   John D. Polstra & Co., Inc.                Seattle, Washington USA
   "Self-knowledge is always bad news."                 -- John Barth

In article <3ptc85$ij5@offas_dike.sbil.co.uk>,
Marc Shepherd <shepherd@debussy.sbi.com> wrote:
>
>Notwithstanding the ARM rule, I believe most implementations actually
>do initialize all static objects before main begins execution.  Consider
>the consequences if it didn't work this way.  The compiler would have to
>put run-time checks into every function, checking whether the necessary
>initializations for that function's original translation unit had been
>performed yet.

 Not true. It is easy to conceive DLL's being linked
an intialised "on demand" after main begins.

 On the 486 processor this is trivial to implement,
and does not require any run time checks in code at all.
All it requires is a data segment which is NOT
loaded at startup. The first reference to data in the DLL
causes a processor exception which then actually
initialises the data segment.

 This avoids initialising a whole lot of guff that
might never be used in a particular use of a program.

 AFAIK Sun has or is attempting something like this,
and for exactly this reason -- to allow a program to start
running very quickly, without virtual memory thrashing
on startup. I guess they'd be using demand paged memory
to do the same thing.


--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <3q2n6f$f7u@ibbr.ib.be>,
Raoul De Kezel  <raoul.de.kezel@infoboard.be> wrote:
>shepherd@debussy.sbi.com (Marc Shepherd) wrote:
>[snip]
>>Ideally, I suppose one would like to have a finer-grained control over
>>when global objects are initialized.  I understand the standards-writers
>>wrestled with this for a while, but could not devise a sensible syntax
>>for it--so the timing of such initializations was left unspecified (other
>>than a few minimal guarantees).
>
>Was it only a syntax problem ?

 No.

>Is there some records of the discussions about this subject ? I'm  very
>interested by the proposed solutions, why they were not adopted, etc.

 A reasonable solution _was_ formulated. It was withdrawn.
The main reason was uncertainty -- no one really knows what effect
it would have had on compilers.

 A second problem is that the proposed solution was MANUAL.
It required knowledge of implementation details to operate.

 It is generally accepted an automatic solution isn't
possible unless dynamic switches are used for every reference to
every global in a program -- an overhead not considered acceptable.

 Static analysis cannot determine usage, not even
global analysis -- hence a manual solution.
--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article 95May20120237@cinder, hcobb@slip.net () writes:
>
>The C++ FAQs book, question number 180: (WRT file scope static
>objects)"...Their constructors are invoked before main() begins
>executing..."
>
>I used to believe this, and had a system where entire modules where
>simply presented to the linker and bound in with the program (by having
>a FSSO register itself with a singleton.)
>
>But I reread the ARM and noticed that the actual rule was "...is done
>before the first use of any function or object defined in that
>translation unit" (ARM: 3.4)
>
>This makes considerable sense, if you consider a program that only drags
>a great deal of DLL objects in on rare executions. (Otherwise you pay
>the startup cost of every "module" that might be invoked, at the start
>of each run)
>

Notwithstanding the ARM rule, I believe most implementations actually
do initialize all static objects before main begins execution.  Consider
the consequences if it didn't work this way.  The compiler would have to
put run-time checks into every function, checking whether the necessary
initializations for that function's original translation unit had been
performed yet.  (The checks could be omitted for functions defined in a
translation unit that had no global variables requiring initialization.)

Now, in some applications, the cost of those run-time checks would be
unacceptable.  Also, in a program having zillions of very little functions
(which is common in C++), a lot of extra code would be generated.  All
in all, you really *are* better off if all initialization takes place
before main starts executing.

Ideally, I suppose one would like to have a finer-grained control over
when global objects are initialized.  I understand the standards-writers
wrestled with this for a while, but could not devise a sensible syntax
for it--so the timing of such initializations was left unspecified (other
than a few minimal guarantees).

---
Marc Shepherd
Salomon Brothers Inc
shepherd@schubert.sbi.com The opinions I express are no one's but mine!

shepherd@debussy.sbi.com writes:
>Notwithstanding the ARM rule, I believe most implementations actually
>do initialize all static objects before main begins execution.

The main exception is that you can defer initialization of static objects
in shared libraries (DLLs for Windows folks) until the time at which the
libraries are first referenced (or explicitly linked to: "dlopen" for
SVR4 folks).  This can be done without additional expense and may in
fact be cheaper.




--
-- Joe Buck  <jbuck@synopsys.com> (not speaking for Synopsys, Inc)
Phone: +1 415 694 1729

>>>>> Marc Shepherd <shepherd@debussy.sbi.com> writes:

> Notwithstanding the ARM rule, I believe most implementations actually
> do initialize all static objects before main begins execution.  Consider
> the consequences if it didn't work this way.  The compiler would have to
> put run-time checks into every function, checking whether the necessary
> initializations for that function's original translation unit had been
> performed yet.

Not necessarily.  Here are two possible schemes to avoid massive overhead:

1) Always call through a jump table of some sort, and make all jump table
   entries point to stub functions.  When a stub function is called, it
   runs any necessary initializers, updates its table entry to point to the
   real function, and hands off to the real function.

2) Defer running the initializers for a shared library until it is actually
   mapped into the program (and don't map it in until it is actually
   needed).  More generally, some sort of OS support for running
   initializers the first time a particular page is loaded from disk.

Jason

The C++ FAQs book, question number 180: (WRT file scope static
objects)"...Their constructors are invoked before main() begins
executing..."

I used to believe this, and had a system where entire modules where
simply presented to the linker and bound in with the program (by having
a FSSO register itself with a singleton.)

But I reread the ARM and noticed that the actual rule was "...is done
before the first use of any function or object defined in that
translation unit" (ARM: 3.4)

This makes considerable sense, if you consider a program that only drags
a great deal of DLL objects in on rare executions. (Otherwise you pay
the startup cost of every "module" that might be invoked, at the start
of each run)

--
 Henry J. Cobb hcobb@slip.net ftp://ftp.cdrom.com/pub/misc/sfb
All items Copyright (c) 1995, by their respective authors, permission is
granted to redistribute as long as proper credit is given.