beshers@select.columbia.edu (Clifford Beshers) (10/20/88)
The following program suffers a memory fault before it ever gets
to the first line of main(). The problem lies in the constructor
of the global instance 'example hello'; the reference to the
cout stream occurs before the initialization of that stream.
Because global instances are initialized in the order in which
they are declared, this is expected; only external references to
these streams are present in stream.h, and so their actual
declaration gets packaged into libC.a.
So, the question, is there any way around this? It seems like
this would problem would exist for *any* class instances are
declared in some library. Sure, I don't *really* need this
feature, but it is nice.
***************************** Cut Here *******************
// The following code illustrates a problem with the interaction
// of global constructors of user defined objects and with the
// global constructors of system defined objects, namely standard
// I/O streams.
#include <stream.h>
class example {
public:
example()
{
cout << "Hello, world\n";
}
};
// Comment out this line and it works, of course.
example hello;
main()
{
cout << "We never get to the first line...\n";
}
Cliff Beshers
Columbia University Computer Science Department
beshers@sylvester.cs.columbia.edutek@fenix.Atlanta.NCR.COM (Tom Klempay) (10/21/88)
In article <5955@columbia.edu>, beshers@select.columbia.edu (Clifford Beshers) writes: > The following program suffers a memory fault before it ever gets > to the first line of main(). The problem lies in the constructor > of the global instance 'example hello'; the reference to the > cout stream occurs before the initialization of that stream. > <some stuff deleted> > > #include <stream.h> > class example { > public: > example() > { > cout << "Hello, world\n"; > } > }; > // Comment out this line and it works, of course. > example hello; > main() > { > cout << "We never get to the first line...\n"; > } Just to further muddy the waters, I just tried this with Zortech C++ (1.05), and the output is : c>foo We never get to the first line... c> It compiles fine (i.e. at least there were no errors or warnings :-), but, as shown above, it ignores the constructor output when "hello" is globally declared. Something strange going on here since it bombs on you but works (somewhat) for me. Tom Klempay - NCR SE-Retail | #ifndef _DISCLAIMER Atlanta, GA | #include <disclaimer.std> tek@fenix.atlanta.ncr.com | #endif ...!ncrlnk!fenix!tek |
prl@iis.UUCP (Peter Lamb) (10/22/88)
In article <5955@columbia.edu> beshers@select.UUCP () writes: > The following program suffers a memory fault before it ever gets > to the first line of main(). The problem lies in the constructor > of the global instance 'example hello'; the reference to the > cout stream occurs before the initialization of that stream. > Because global instances are initialized in the order in which > they are declared, this is expected; only external references to > these streams are present in stream.h, and so their actual > declaration gets packaged into libC.a. I was going to mail this to beshers@select, but I ended up writing a reasonably long section about handling cross-file global constructor dependencies, so I have posted to news instead. I compiled and ran your code and it gave me exactly the right answer; ie it printed Hello, world We never get to the first line... [[ I deleted the example. 'Hello, world' is printed by a static constructor, `We never...' is printed by main() ]] Also note; global (and file static) instances are executed in the order that they are *defined*, not the order of their *declaration*. It appears that there is something wrong with either your library or your CC script. Possibly the library object files are in the wrong order in the library. This order is of paramount importance. Another possibility is that `munch' isn't being run correctly and/or its output isnt being compiled and linked into your program. CC should do the following: Compile any C or C++ code to object Link the object modules, if no errors, then run nm -pg <executable> | munch > __ctdt.c Compile __ctdt.c Re-link the object modules, including __ctdt.o. nm must be run with the -p flag on BSD. I seem to remember that CC as distributed had nm without flags. I tried changing the nm flags to just -g, and it crashed in exactly the way you mentioned. I think that this is most likely your problem. > So, the question, is there any way around this? It seems like > this would problem would exist for *any* class instances are > declared in some library. Sure, I don't *really* need this > feature, but it is nice. Although the streams and other libC classes should work properly, you are quite right in believing that initialisation of static objects whose correct initialisation depends on the initialisation of other static objects is something that is *very* hokey in C++. It _is_ very useful; the problem is that the Unix, and most other, loaders are too dumb. Some rules of thumb for doing this are (this assumes BSD4.[23]. I am not familiar enough with the finer points of the SysV ld and loader utilities to know if all of these things will work there): 1) Don't overuse the feature and try to avoid (where possible) static objects that depend on the initialisation of static objects in other files. 2) Use explicit loads of object modules rather than libraries. You have more control over them. The BSD loader and munch together will ensure that the static constructors in the last-mentioned files (and libraries) will be executed before those in the earlier modules. Static destructors will be called for the object files left-to-right. 3) If you need to put interdependent static objects in libraries use the old Unix v7 commands lorder and tsort to try to persuade the objects to be put into the library in the correct order: eg, for make: universal_class_lib.a: $(OBJECTS) rm -f universal_class_lib.a ar crv universal_class_lib.a `lorder $(OBJECTS) | tsort` ranlib universal_class_lib.a # This isn't needed for SysV If tsort doesn't complain about cycles in the data, the library will probably load in the correct order. If you can't get this to work, you will have to order the library by hand, or prehaps rearrange your objects in their files. 4) The order of initialisation between object files is *not* defined as part of the language. So none of the above need necessarily work. Static constructors should be able to do IO through streams, and the mechanisms which allow this will probably mean that the other techniques will work as well. It is a great pity that this can't be done *much* better, but Unix (and most other) loaders are just too dumb (there are good reasons for loaders to be dumb, too, unfortunately...). -- Peter Lamb uucp: seismo!mcvax!ethz!prl eunet: prl@ethz.uucp Tel: +411 256 5241 Institute for Integrated Systems ETH-Zentrum, 8092 Zurich
mikem@otc.oz (Mike Mowbray) (10/24/88)
In article <5955@columbia.edu>, beshers@select.columbia.edu (Clifford Beshers) says: > The problem lies in the constructor of the global instance [...] > the reference to the cout stream occurs before [its] initialization ... This is a problem that recurs now and then. I will re-post my original answer to the problem here anyway, since it is quite some time since this question was asked. > Because global instances are initialized in the order in which they are > declared, this is expected; Actually, this is not quite true - they are usually called in the order in which they are linked, which is the reverse of what you want. > So, the question, is there any way around this? To fix it, you must have the source of munch. (Patch users will need to do the fix by figuring what changes are needed in patch). Here are the diff's: $ diff lib/static/munch.c.orig lib/static/munch.c.new 36,37c36,38 < sbuf* dtor; // list of constructors < sbuf* ctor; // list of destructors --- > sbuf* dtor; // list of destructors > sbuf* ctor; // list of constructors > sbuf* tail; // tail of list of constructors 63c64,69 < ctor = new sbuf(ctor,st); --- > register sbuf *newctor = new sbuf(NULL, st); > if (tail != NULL) > tail->next = newctor; > else > ctor = newctor; > tail = newctor; $ I.e: make the list of ctors in the opposite order instead. Examine what is going on in munch and you will see what I mean about the order of calling static ctors. Note that static dtors are OK since you want them to be called in reverse order to static ctors. To understand all this you will also need to examine the otehr files in lib/static - cfront is arranging for an _main() function to be called at the start of main(), which calls a list of ctor functions which munch sets up. Mike Mowbray Network R&D |||| OTC || ACSnet: mikem@otc.oz TEL: (02) 287-4104 UUCP: {uunet,mcvax}!otc.oz!mikem SNAIL: GPO Box 7000, Sydney, Australia
bright@Data-IO.COM (Walter Bright) (10/25/88)
In article <386@fenix.Atlanta.NCR.COM> tek@fenix.Atlanta.NCR.COM (Tom Klempay) writes: >In article <5955@columbia.edu>, beshers@select.columbia.edu (Clifford Beshers) writes: << The following program suffers a memory fault before it ever gets << to the first line of main(). The problem lies in the constructor << of the global instance 'example hello'; the reference to the << cout stream occurs before the initialization of that stream. << #include <stream.h> << struct example { << example() { cout << "Hello, world\n"; } << }; << example hello; // Comment out this line and it works, of course. << main() { cout << "We never get to the first line...\n"; } <Just to further muddy the waters, I just tried this with Zortech C++: <c>foo <We never get to the first line... <c> <It compiles fine (i.e. at least there were no errors or warnings :-), but, as <shown above, it ignores the constructor output when "hello" is globally <declared. Something strange going on here since it bombs on you but works <(somewhat) for me. There is nothing strange going on here. cout requires, in order to work, the static constructor for cout to be called. In C++, the order in which module constructors are called is not specified when they appear in different modules. In the example above, cout was not initialized when example::example() was called, producing random behavior. Morals: 1. Don't use stream I/O in constructors. 2. Don't depend on the order in which module constructors are called. Definition: Module constructor: the function inserted by the C++ compiler into each compilation unit (module). This function calls all the static constructors for that module, and also does any static initialization that cannot be done at compile-time.