In article <3k0lpa$4s@news.primenet.com>, Derek Jones <dtj@Primenet.Com> wrote:
>I used to think that the power of object files was that you could link
>together routines written in different languages, choosing the language
>that best fit the problem for each part of the final application.
>I've done this, but there is a real problem with doing it:
>
>There is no STANDARD in any language for linking different languages
>together, as far as I can see, except for the 'extern "C"' directive
>in C++.

A brief look at appendix B of the new ISO Ada 95 standard seems to indicate
that you are wrong about that.

It appears that the Ada folks have done quite a bit of detailed work to
support the linking & interfacing of Ada 95 code with code written in C,
Fortran, or COBOL.

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- E-mail: rfg@segfault.us.com ----------- Purveyors of Compiler Test ----
-------------------------------------------- Suites and Bullet-Proof Shoes -

I used to think that the power of object files was that you could link
together routines written in different languages, choosing the language
that best fit the problem for each part of the final application.
I've done this, but there is a real problem with doing it:

There is no STANDARD in any language for linking different languages
together, as far as I can see, except for the 'extern "C"' directive
in C++.

This is a part of the C++ language that specifically addresses the
linking issues with another language.

Because the "C" in 'extern "C"' is a string, it makes me wonder if
there are any plans to have an 'extern "FORTRAN"' or 'extern "PASCAL"',
etc.

When you are developing an application that is meant to port quickly
to new architectures and new O/S's with very little rewriting,
it is important to rely ONLY on those features which are described in
the language standard, and not on any vendor peculiarities.

However, it seems that in the realm of linking together different
languages, there is no help EXCEPT for vendor peculiarities, even
in spite of the fact that C, C++, FORTRAN 77, Fortran 90, Pascal, and
Ada are all (at their core) procedural, stack-based languages.  I realize
that linking with LISP or any other interpreted language poses problems
related to language architecture.

The message I seem to be receiving from the industry is:  don't write
your application in more than one language.  This seems unfortunate
because it implies that there will someday be one best, all-encompassing
language, which I'm not sure I believe.  When thinking back to college,
I realized that not one computer science class I took ever even hinted
that languages could be linked together.

I know that standards like DCE, RPC, SOM/DSOM, and so forth, deal with
linking together different architectures at run-time; yet, all the
examples I see involve C or maybe C++ (using extern "C" to take advantage
of the features).

So does anyone know:  will anything ever follow "extern" except "C"?

-------------------------------------------------------------------------------
Derek Jones
dtj@primenet.com
-------------------------------------------------------------------------------


--
-------------------------------------------------------------------------------
Derek Jones
dtj@primenet.com
-------------------------------------------------------------------------------

In article <3k0lpa$4s@news.primenet.com>, dtj@Primenet.Com (Derek Jones) writes:
:
: There is no STANDARD in any language for linking different languages
: together, as far as I can see, except for the 'extern "C"' directive
: in C++.

Wrong.  The revised Ada standard (ISO since 15 February 1995) offers
the normative "Annex B: Interface to Other Languages."  Here's the first
paragraph and the TOC of that annex:

  (1) This Annex describes features for writing mixed-language programs.
  General interface support is presented first; then specific support for
  C, COBOL, and Fortran is defined, in terms of language interface
  packages for each of these languages.

  Clauses and Subclauses

    1.Interfacing Pragmas
    2.The Package Interfaces
    3.Interfacing with C
         1.The Package Interfaces.C.Strings
         2.The Generic Package Interfaces.C.Pointers
    4.Interfacing with COBOL
    5.Interfacing with Fortran

GNAT (GNU Ada) has facilities to interface with C++ (including dynamic
binding with C++ objects) and SGI has a tool to automatically generate
Ada interfaces to their C++ libraries.

The Ada 95 Reference Manual is online as a hypertext document, at URL
 http://lglwww.epfl.ch/Ada/LRM/9X/rm9x/rm9x-toc.html

The Ada 95 Rationale is also online as a hypertext document, under URL
 http://lglwww.epfl.ch/Ada/Resources/References.html


: The message I seem to be receiving from the industry is:  don't write
: your application in more than one language.

It depends on what level of support a given language gives for language
interfaces.

--
Magnus Kempe  "I know not what course others may take, but as for me,
Magnus.Kempe@di.epfl.ch  Give me Liberty... or give me Death!" -- Patrick Henry

Derek Jones (dtj@Primenet.Com) wrote:
: Because the "C" in 'extern "C"' is a string, it makes me wonder if
: there are any plans to have an 'extern "FORTRAN"' or 'extern "PASCAL"',
: etc.

Probably not.  It would be a good idea, but the de facto standard that has
grown up seems to indicate that linking to other languages is done with
keyword extensions to the decl-specifier such as `__pascal' or
`__declspec(dllexport)'.

Of course, it would be *nice* to have `extern "PASCAL"' and suchlike, so
that we can separate name mangling modifiers from calling convention
modifiers (currently accepted extensions such as `__pascal' do the jobs of
both name mangling and calling convention modification in one, which is
ugly, inextensible, and horrible), but I don't see that happening, do you ?

---BEGIN--- Obligatory half-baked language modification proposal

Divide declaration specifiers up into three groups, each handling different
tasks.  Name mangling modifiers control the name mangling schemes used :

     extern "C"  ( adding an underscore to original name )
     extern "C++"       ( "vendor's own" C++ style mangling of argument types )
     extern "PASCAL"    ( conversion to uppercase )

( You could even use things like `extern "WATCOM C"' for oddball compilers
  which place the underscore in a different place to everyone else. (-: )

Linkage modifiers control specific linkage issues :

     __declspec(dllexport)   ( Item is given an export record for the
          linker to export it from a DLL )

Calling convention modifiers modify the way that parameters are passed and
arguments returned :

     __CC(CALLER_POPS_STACK)
     __CC(INT_ARGS_IN_REGISTERS)
     __CC(CALLEE_POPS_STACK|PUSH_LEFT_TO_RIGHT)

I happen to think that something such as a __CC() modifier (by analogy
with the __declspec() for linkage extensions) is better than retaining
existing keywords such as `__pascal' and `__syscall', because it is both
extensible, and doesn't carry around all of the additional linkage
and name mangling semantics that those older keywords do.

This would look like :

    //
    //  A function exported from a DLL with a PASCAL style name, and using
    //  PASCAL style argument passing and return.
    //
    extern "PASCAL"
    __declspec(dllexport)
    __CC(CALLEE_POPS_STACK|PUSH_LEFT_TO_RIGHT)
    int MyFunction ( unsigned long, char * )
    {
    }

    //
    //  A function exported from a DLL with a C style name, and using
    //  a particular style of register argument passing and return.
    //
    extern "C"
    __declspec(dllexport)
    __CC(INT_ARGS_IN_REGISTERS)
    int MyFunction ( unsigned long, char * )
    {
    }

And if you want the older keywords :

    #define _Export __declspec(dllexport)

    #define _Far16 __CC(CALLER_SWITCHES_TO_16_BIT_STACK)

---END--- Obligatory half-baked language modification proposal

Of course, the dream in the above is that the standards people will even
touch the issue in the first place.  Despite it affecting millions of
programmers out here in the Real World, it is too platform specific an
issue for the language standard, and few of the compiler manufacturers
seem to be willing to even think out the issues ("our keyword extensions
work OK with *our* C++ compiler calling *our* PASCAL/BASIC/FORTRAN compiler").