C++ module ordering (was: segmentation fault on GiNaC-1.2.0 using MinGW on Win XP)

[Gabriel Dos Reis]

"Richard B. Kreckel" <kreckel at ginac.de> writes:

| On 6 May 2004, Ian Lance Taylor wrote:
| > > Please see <http://www.ginac.de/lists/ginac-devel/msg00623.html>.
| >
| > Those bits are the end of my message weren't actually written by me.
| > They were written by some of the C++ compiler hackers at Cygnus.
| 
| So it remains a mystery what was meant by "full runtime dependency
| analysis [...] with no linker mods"?  Sad.
| 
| > 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++%20Attributes
| 
| 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.

I agree.

| A while ago, I've been debugging an industrial application where the
| linker line was basically rearranged automatically based on a self-made
| scheme: a script was extracting dependency ordering information scattered
| by the programmer.  That solution is equivalant to GCC's init_priority.
| The lesson learned from that experience are:
| 
| 1) Most professional C++ programmers are not aware of there being a
|    problem.  Really.  :-(

I think that is far too excessive.

| 2) Even if they are, they are unlikely to get it right.  #-(
| 
| 3) If they don't get it right, debugging code which hasn't even started
|    running yet is intersting.  :-/

agreed too.

-- Gaby