From -8159042763138745513 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,deec59fd1ee296e8 X-Google-Attributes: gidf78e5,public From: rac@intrigue.com (Robert Coie) Subject: Re: init of static objects Date: 1995/06/06 Message-ID: #1/1 X-Deja-AN: 103925172 references: <3q2cig$81a@engnews2.Eng.Sun.COM> <3q550m$b02@vishnu.jussieu.fr> organization: Intrigue Corporation newsgroups: comp.std.c++ In article , maxtal@Physics.usyd.edu.au (John Max Skaller) wrote: : In article <3q550m$b02@vishnu.jussieu.fr>, : Fabrice Clerc wrote: : >What about unreferenced global objects whose ctors have side-effects ? : > : >Does the WP specify whether unreferenced global objects whose ctors have : >side effects must be constructed ? : : Yes it says so -- although it is unnecessary to do so. : Constructors of un-referenced objects which do not have side : efffects can be eliminated no matter what the WP says, by the : "as if" rule -- if you can't tell whether it has been eliminated : or not you can eliminate it. : : On the other hand there is no need to say constructors : of unreferenced objects _with_ side-effects must not be : eliminated, because an object defined in a translatioin unit : is an object of the translation unit -- its there, it IS : part of the program. : : That is the rule is really just a reassurance. : : >On some systems, these objects : >are never constructed (especially if you place them in libraries) ! : : Do not get confused between : : 1) eliminating a global _from_ a specified translation unit : 2) not linking in a particular translation unit : : (1) is NOT allowed. (2) is determined by the implementor. // header struct A { A(); }; typedef void (*pFv)(); void f(); pFv g(); // file1 #include "header" #include A::A() { cout << "hello" << endl; } // file2 #include "header" A a; void f() { } // file3 #include "header" pFv g() { return &f; } // file4 #include "header" int main() { pFv p = g(); (*p)(); return 0; } As I see it, the act of taking the address of f in file3 insures that file2 will not be stripped by the linker. Is an implementation required to call A::A? If so, does such an implementation currently exist? I would think this would be devilishly difficult without abandoning deferred initialization. Robert Coie rac@intrigue.com Implementor, Intrigue Corporation AppleLink: INTRIGUE