Externals

Here is the information you need if you want to call C or Java code from Eiffel code (to call Eiffel feature from C or Java see `cecil` file).

The most common way to call external code from Eiffel is to use the external feature definition as described in the book "Eiffel The Language". See also the SmallEiffel directory `lib_show/external` to have some examples.

Below is the current list of SmallEiffel external specifications.

external "C_WithoutCurrent"

Simple call to a C function (or procedure). The external called routine does not get Current as an argument. A C prototype is automatically added in a generated C header file. Use this when you provide yourself the C code for the external routine.
Note: for compatibility with other Eiffel compilers `external "C"` is treated exactly as `external "C_WithoutCurrent"`.

external "C_WithCurrent"

C call with Current. The external called routine gets Current as its first argument. A C prototype is automatically added in a generated C header file. Use this when you provide yourself the C code for the external routine.

external "C_InlineWithoutCurrent"

Similar to `"C_WithoutCurrent"`, except that no prototype is produced.
Use this if you already have the corresponding prototype coming from somewhere else (`stdio.h` for example), which is likely if you call a routine from a standard C library (e.g. `printf`). Actually, the name is not really well chosen, since "Inline" has little to do with this...

external "C_InlineWithCurrent"

Similar to `"C_WithCurrent"`, except that no prototype is produced.
Use this if you already have the corresponding prototype coming from somewhere else (`stdio.h` for example), which is likely if you call a routine from a standard C library (e.g. `printf`). Actually, the name is not really well chosen, since "Inline" has little to do with this...

external "SmallEiffel"

This external specification is reserved to the SmallEiffel compiler itself. Do not use it. Such a feature is directly supported both by `compile_to_c` and `compile_to_jvm`. For example, infix "+" of INTEGER is direcly mapped as C '+' by `compile_to_c`. For the same infix "+", command `compile_to_jvm` produce the appropriate Java virtual machine byte code.

external "JVM_invokestatic"

Calling a Java static method. As it is a static Java call, the Eiffel receiver is not used. The "alias" field of the feature is used to indicate the Java class, the Java function name and the corresponding Java bytecode descriptor. Syntax to use in the alias string is :

  `alias "<JavaClassPath>.<MethodName> <Descriptor>"`

A dot is the separator between <JavaClassPath> and <MethodName>.
A blank character is the separator between <MethodName> and <Descriptor>.
The <JavaClassPath> uses the JVM internal notation as described in JVMS(*). For example, when one wants to use java.lang.Math, the <JavaClassPath> is "java/lang/Math". The <MethodName> gives the Java method name. The <Descriptor> gives the internal Java bytecode descriptor as described in JVMS(*).

    (*) - JVMS -
       "The Java Virtual Machine Specification",
       Tim Lindholm and Frank Yellin, The Java Series,
       Addison-Wesley, ISBN 0-201-63452-X.

external "JVM_invokevirtual"

Calling a Java virtual method. As for "JVM_invokestatic", the alias string gives all needed information to call the virtual function. The Current Eiffel target is not used (only arguments and the result are considered).

Inlining C code

Another way to call C code from Eiffel is to use "c_inline_c" or "c_inline_h" as defined in GENERAL. The argument of "c_inline_c" (or "c_inline_h") must always be a manifest string which may contains the C code you want to put inlieu.
Using c_inline_[c/h] also implies you do know exactly the C code SmallEiffel produces. For portability, it is also much better to use previous solutions.
People who tinker with the C code generated by SmallEiffel, not limiting themselves to the Cecil and/or external interfaces, should also read this page about the C code generated by SmallEiffel, Otherwise they might get into trouble.

Copyright © Dominique COLNET and Suzanne COLLIN - <colnet@loria.fr>
Last update: 05 May 1999, by OZ.