On Wed, 24 Oct 2001, Martin v. Loewis wrote: > I'd say that the best solution would be to get rid of globals. This is > actually very easy: > > If you have > > TYPE VAR = INITIALIZER; > > replace that with > > TYPE& getVAR(){ > static TYPE obj = INITIALIZER; > return obj; > } > > Then use getVAR() whereever you've used VAR before. For backwards > compatibility, you can even do > > #define VAR (getVAR()) > > In understand that modules don't share global objects (perhaps except > for the module singleton), so removing global should be a local change > inside each module only.
I don't like this `construct on first use' idiom at all, aesthetically. I find it disgusting to use a function call for that and a preprocessor symbol. But maybe I'll do something else in the mid-term future. We've been using this `construct on first use' idiom until recently in GiNaC for flyweights and last week I finally got rid of them by setting them up similarly to how libstdc++-v3 sets up cin, cout, etc (i.e. section 27.4.2.1.6). That requires us to have a single controller module that explicitly knows about the dependencies, but since there are only 43, as you have noticed, this might be an option worth considering. > > The best solution would be to teach the linker about it. > > The linker actually does know about constructor order. In g++, there > is a guarantee that object files within the same executable or shared > library are initialized from right to left, in the order in which the > objects appear on the linker line. Arguably, that order is too simplistic. It should analyze the dependencies among the globals, see if they form a DAG and rearrange the order so that the DAG is traversed correctly when the library/program fires up. > > The solution we are talking about here is just a rather > > unconventional but beautiful one. > > Looking at the code in module.h, I'd question that there is anything > beautiful about it. No, the macros are obscene, as mentioned in the comment! :-) But the way one can use them is quite nice, I'd say. > > Rather than that or changing the module ordering macros and writing > > autoconf scripts to see if the global dtors are making use of > > cxa-atexit I guess I'll just switch on -fno-use-cxa-atexit in CLN > > whenever GCC-3.x is used. Hope this'll work for a couple of > > years... > > I very much doubt that. Somebody will notice that the _GLOBAL__ > symbols don't need unique names at all, since they are not global (in > fact, static_initialization_and_destruction is already in gcc 2.95 a > single function for both ctors and dtors, so it is questionable > whether these "clever" macros really get the control flow right). > > Furthermore, the C++ ABI really specifies that the .init and .fini > sections shouldn't be used for constructors and destructors. For > constructors, .initarray should be used, to allow portable integration > of constructors across different compilers. Destructor sections should > not be used, instead, cxa_atexit won't be an option at some time in > the future. Aha. Thanks for that input! Regards -richy. -- .''`. Richard B. Kreckel : :' : <[EMAIL PROTECTED]> `. `' <[EMAIL PROTECTED]> `- <http://www.ginac.de/~kreckel/>