Slashdot Mirror


The Challenge of Cross-Language Interoperability

CowboyRobot writes "David Chisnall of the University of Cambridge describes how interfacing between languages is increasingly important. You can no longer expect a nontrivial application to be written in a single language. High-level languages typically call code written in lower-level languages as part of their standard libraries (for example, GUI rendering), but adding calls can be difficult. In particular, interfaces between two languages that are not C are often difficult to construct. Even relatively simple examples, such as bridging between C++ and Java, are not typically handled automatically and require a C interface. The problem of interfacing between languages is going to become increasingly important to compiler writers over the coming years."

5 of 286 comments (clear)

  1. Java, C++ by stenvar · · Score: 4, Informative

    The fault here lies specifically with Java and C++. Java's JNI is poorly designed and makes no serious attempt to make interoperability easy because it is against Java's philosophy. C++'s runtime is deliberately completely implementation dependent because C++'s designers thought that might let implementors squeeze out a little bit of performance.

    Nevertheless, tools like Swig make even Java/C++ interoperation fairly easy, and many other languages try to accommodate C++ well (cf. Boost::Python).

  2. Re:this kind of comment system is dead by stenvar · · Score: 4, Informative

    I don't even know why anyone would even bother with c++. If it's a good fit, just use c.

    Because C++ lets people automate resource management and error handling, things that in C are manual and error prone. C++ also provides standards for abstraction, encapsulation, and substitutability, something that in C is not standardized and handled differently by every library. Despite C++'s many flaws and unnecessary complexity, it still is a better language than C for many projects.

  3. Re:Cross language - what .Net gets right by gigaherz · · Score: 4, Informative

    Not true. .NET assemblies are able to use both standard exports (C functions), and COM libraries (which can be coded in C, C++, VisualBasic 6, ...), and can also export COM interfaces to the .NET classes and through the use of assembly modification tools, also export C functions.

  4. Re:Cross language - what .Net gets right by cardpuncher · · Score: 4, Informative

    VMS was mostly written in BLISS, although there were chunks of Macro-32, particularly in the drivers. The big challenge in the Alpha port was effectively cross-compiling the Macro-32 code for Alpha hardware. Towards the end of Digital as an independent company, more development work was done in C.

    An early decision in the design of VAX/VMS was the definition of the "VAX Procedure Calling Standard" that dictated the instructions and mechanisms to be used for calling procedures, passing parameters and returning values, independent of language. All the compilers were expected to use this mechanism so that you could, for example, call a procedure written in VAX COBOL from VAX FORTRAN. This worked to a large extent, but it wasn't explicitly defined (and couldn't really be defined) whether compilers should use call-by-value, call-by-reference or call-by-descriptor for particular data types so additional semantic cruft was required to sort out the deails of parameter-passing. VAX C would sometimes pass a double-word argument in violation of the standard. The standard also had nothing to say about meta issues like run time initialisation, memory and thread usage, etc.

    That said, it was a revelation coming from an IBM world in which you'd sometimes have to write Assembler shims to patch up the calling conventions if you needed to get one language talking to another.

  5. Re:Cross language - what .Net gets right by TheRaven64 · · Score: 4, Informative

    VMS managed to get the idea of the platform ABI specifying procedure call conventions right very early on. It had quite an easy job though. C, BASIC and Fortran are all structured programming languages with basically the same set of primitive types. None of them have (or, in the VMS days, had) classes, late binding, or real garbage collection. BASIC is kind-of GC'd, but it doesn't have pointers and so everything passed across the language barrier from BASIC was by value, so the GC didn't have to do anything clever.

    It's worth remembering that when VMS was introduced, other platforms were still having problems getting C and Pascal to play nicely together (Pascal pushing arguments onto the stack in the opposite order to C), so that's not to belittle the achievement of VMS, but it's a very different world now that we have Simula and Smalltalk families of object orientation, various branches of functional languages, languages like Go and Erlang with (very different) first-class parallelism, and so on.

    --
    I am TheRaven on Soylent News