Re: extern "C" ... again

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance



Pelle wrote:
[..] if there is no rule to old-style C name mangling, how is the
linker to find the referred function? Imagine I use a 3rd party
library which has been built with a different compiler/linker, is it
still enough to specify <extern "C"> when using this library?

Name mangling follows a convention. The names are not random, there is some logic to it, do you agree? It's not impossible to imagine that the convention can be put in writing by the compiler developer and shared with other developers, yes? Let's take an opposite and imagine what would happen if it were true. What if car manufacturers instead of using the same 12 volts for their electrical systems would each use something different, 10 volts for one, 16 volts for another, 13.33 volts for the third and so on? Doesn't make sense, does it?

On the same operating system the software developers follow the recommendations of the OS developers when it comes to establishing their conventions. Take dynamic libraries for example. Windows is based on those. Functions in them have to have at least the ordinal number to be accessible from outside. Next, take static libraries. Development of stand-alone executables can be done without them, but why would anyone want to go to so much trouble? So, the OS manufacturer supplies at least the libraries to interface with the OS functionality. Now, if the compiler/linker is capable of using those libraries, why not make those requirements a convention and let any library to be usable in the same way?

Example: Intel C/C++ compiler follows Microsoft's convention for name mangling, so the object modules it produces are fully compatible with what Microsoft C/C++ compiler expects (and vice versa).

Not sure if this answers your question. If not, ask more question, I guess.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
.



Relevant Pages

  • Re: ARM IDE
    ... the source I could fix it" which is why I am very unconvinced when people say having the course of a compiler is useful ... An experienced developer of a high level is going to be just as capable of understanding, debugging and correcting a toolkit's library as the library developers are - assuming there is decent information available about things like calling and naming conventions in the library. ... There is no need for the library to be under any kind of open source license. ... I dislike any tools which don't include source for their libraries - the source is the final word in the library documentation, and it is sometimes very useful when debugging my own code. ...
    (comp.arch.embedded)
  • Re: Garbage collection problems
    ... and they can make dlls and static libraries. ... convention, then they are unable to use really any code (static libraries, ... and the compiler becomes essentially useless. ... and the Win64 calling convention. ...
    (comp.lang.c)
  • Re: C++ lib compatibility between Red Hat 9 and 7.3
    ... That's why developers who distribute source are usually fairly clear ... > compiler that is the problem. ... So if a library contains a routine ... Actually, if you have two libraries with the conflicting symbols, ...
    (RedHat)
  • Re: Vexing problems arising from mixing F9x and F77 code
    ... from the IBM Fortran IV G and IBM Fortran IV H even though they ... should be equal to or later version than the compiler. ... The calling convention was fairly ... libraries from the two compilers initially. ...
    (comp.lang.fortran)
  • Re: Prototype - Good/Bad/Why?
    ... related to browser scripting. ... tested with IE7 and the app and jquery work fine with it. ... sniffing libraries), your application will be forever stuck in the IE ... The developers should be chosen according to the goals of the ...
    (comp.lang.javascript)