Ian Lance Taylor <ian@wasabisystems.com> writes: | "Richard B. Kreckel" <kreckel@ginac.de> writes: | | > So it remains a mystery what was meant by "full runtime dependency | > analysis [...] with no linker mods"? Sad. | | Oh, no, I know what that means. It means that the compiler itself | looks at the constructor and determines what other objects it | references. The compiler itself then ensures that any constructor for | those other objects are run first. The compiler should be able to do | a more reliable job than the linker. | | One way to do that would for the compiler to generate entries in a | special section for each global constructor. Each entry in the | section would simply be the name of the global constructor and the | name of another object upon which it depends. The linker could then | gather that information together and build a topographical map, and | use that map to construct a constructor ordering, much as is done in | Bruno's existing patch. Circular dependencies would be detected at | link time. | | > > Are you familiar with the init_priority attribute supported by g++? | > > It seems to me that it handles most of the problems associated with | > > static object initialization order. | > > http://gcc.gnu.org/onlinedocs/gcc-3.4.0/gcc/C---Attributes.html#C++%20Attrib... | > | > Sure, but that is only pampering about the real problem: Who establishes | > the PRIORITY variables? The programmer would have to do it manually. | > Any programmer is likely to get it wrong if confronted with several | > hundreds or even thousands of modules. Working with an automated | > mechanism is much less prone to errors. Hence init_priority is not at all | > an acceptable solution, IMNSHO. | | Well, even with many modules, you can divide and conquer the problem. | Normally modules come in groups, and you can determine a topographical | sort of the group. Then you can assign number ranges to the groups. | Then within each group, you can do the right thing. I suspect Ricky's point is preceily that if that sektch of algorithm is workable, then it should be tajen care of by the compiler -- those are simply too much of low level details and the compiler/linker has more information that it could pass around. | If there are | circles in the group graph, then you have a problem, but in that case | I suspect that you have a deeper design problem as well. yep, but then it would be helpful if such circles are reported by the compiler/linker as it is processing the translation/instantiation units. In presence of templates and "deferred" instantiations, that even makes more sense where one gets all sorts of headaches. See http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#362 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#270 | The other simple approach is to not use global constructors, or at | least not global constructors in which there are cross-module | dependencies. You instead pay a cost to check that the objects are | initialized before they are used. In practice I suspect this cost | would be quite small. Well, I'm not sure :-) -- Gaby