Re: Linker ... still useful ?

Rob MacLachlan <ram+@cs.cmu.edu> writes:


        1] Namespace -- Most linkers implement a more or less flat namespace,
        whereas most modern languages don't. This can be handled to some degree
        by prefixing, but that clearly isn't the best solution. In general linker
        names become little more than random unique IDs, and some pre-linker phase
        must make sure that the names really are unique.


        2] Interface compatibility -- Ideally, many aspects of interface
        compatibility checking would be put off until link time. In practice, few
        linkers have any support for compatibility checking.


The Inmos Toolset linker does both of these, and the debugger supports
occam2's nested namespace quite well. (Well, given the nature of the language
and the processor, it wouldn't work at all if it didn't...) The debugger does
get confused once in a while.


        3] Initialization -- Most modern languages have a concept of more-or-less
        anonymous chunks of initialization code which are run before the main
        entry.


The VMS linker has supported this very early on, in a very flexible way. Only
few compilers seem to make use of this. Probably ADA does, and FORTRAN seems
to do in some situations.


Jan
[C++ needs this feature for global class instances with initializers. Given
the wild success of C++, we'll probably be seeing more linker support.
Fortran doesn't need initialization code, although some compilers (one of the
PDP-10 compilers, for example) used it to initialize large sparse data arrays
and make the object file smaller. -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.