For IBM C ++ on AIX (aka xlC and C Set ++), I made the intentional decision
to link in ALL static objects that needed construction, even if they were in
libraries.  This prevents a program's behaviour from changing if a .o file
is renamed to a '.a' file.  There is, of course, and option to get the
'only referenced objects' behaviour.
--
Mark Mendell
C Set ++ for AIX Development
IBM Toronto Lab
mendell@vnet.ibm.com

In article <chopps-0606951814010001@wine.emich.edu>,
chopps@water.emich.edu (Christian E. Hopps) wrote:
> The problem for me is with the standard specifically 3.6.2
> (basic.start.init).
>
> Basically I believe that Codewarrior and John's interrpretation are
> incorrect.  The standard says that you cannot eliminate static objects
> with constructors with side-effects.  Delaying construction forever,
> i.e. until some function that can never be called gets called (it and
> the rest of the file have been eliminated) Is eliminating the object.
>
> No need to be tricky.  If you don't construct something your eliminating it.

I started thinking about libraries and how only files that contained
refrenced items get linked in.  It seems reasonable that the compiler/linker
can treat project files the same way.

Sorry for the noise.

Chris.

In article <chopps-0606951814010001@wine.emich.edu>,
chopps@water.emich.edu (Christian E. Hopps) wrote:

> incorrect.  The standard says that you cannot eliminate static objects
> with constructors with side-effects.  Delaying construction forever,

A "static" declared object is not the same as a static object. The way the
Metrowerks linker works is the correct interpretation of the standard, and
the way most modern linkers do it.

Cheers,

   / h+

In article <phils-0606951335470001@155.64.60.59>,
phils@bedford.symantec.com (Phil Shapiro) wrote:

> In article <D9KMoo.8AK@world.std.com>, johnmce@world.std.com (John
> McEnerney) wrote:
> | Our interpretation of this clause is that we are deferring the
> | initialization to the first use of a function (or object) in that
> | translation unit. So if a function in that translation unit is called, I
> | promise we'll initialize the static object before that.
> | Since that will never actually happen, I see no reason to actually link
> | the code into the application. :-)
>
> This is the same behavior as implemented by the THINK Project Manager --
> although due to the way projects are launched at debug time, the behavior
> is different for debugged vs. final built applications.
>
> Although the behavior is technically correct, we received a number of
> complaints about it; the linker in the 8.0 SPM does *not* remove static
> objects if they cause any code (eg calls to constructors) to be generated.

The problem for me is with the standard specifically 3.6.2
(basic.start.init).

Basically I believe that Codewarrior and John's interrpretation are
incorrect.  The standard says that you cannot eliminate static objects
with constructors with side-effects.  Delaying construction forever,
i.e. until some function that can never be called gets called (it and
the rest of the file have been eliminated) Is eliminating the object.

No need to be tricky.  If you don't construct something your eliminating it.

But who cares!?  I can't think of a real world example where this matters.
Thats becuase, even if you have a completely self contained translation unit
that does something usefull, you have no idea when that something will happen
(again 3.6.2)

Now if 3.6.2 is changed to guarentee that static objects get constructed
before main() is called then having a stand-alone translation unit becomes
usefull.  You could have a object that prepared the application environment
(i.e. through system operations only) perhaps patching or whatever.

As it stands I see no reason for the standard to insist on construction
of a static object "even if it appears to be unused". The object's
creation time is so non-deterministic that it renders the use of said
object useless.

Chris.