| Foreign Function Interface |
Article Index for Foreign |
Website Links For Foreign |
Information AboutForeign Function Interface |
| CATEGORIES ABOUT FOREIGN FUNCTION INTERFACE | |
| application programming interfaces | |
| programming language topics | |
|
It should be noted that despite the name, FFIs are not necessarily restricted to Function Call s; many FFIs permit Method Call s on objects; and some even permit migration of non-trivial datatypes and/or objects across the language boundary. The term foreign function interface is generally not used to describe multi-lingual runtimes such as the Microsoft Common Language Runtime , where a common "substrate" is provided which enables any CLR-compliant language to use services defined in any other. In addition, many distributed computing architectures such as the Java Remote Method Invokation (RMI), RPC , CORBA , and SOAP permit different services to be written in different languages; such architectures are generally not considered FFIs. In most cases, a FFI is defined by a "higher-level" language, so that it may employ services defined and implemented in a lower level language, typically a systems language like C or C++. This is typically done to either access OS services in the language in which the OS' API is defined, or for performance considerations. Many FFIs also provide the means for the called language to invoke services in the host language as well. OPERATION OF A FFI The primary function of a FFI is to mate the semantics and calling conventions of one programming language (the ''host'' language, or the language which defines the FFI), with the semantics and conventions of another (the ''guest'' language). This process must also take into consideration the Runtime Environment s and/or Application Binary Interface s of both. This can be done in several ways:
FFIs may be complicated by the following considerations:
EXAMPLES Examples of FFIs include:
In addition, many FFIs can be generated automatically: for example, SWIG . EXTERNAL LINKS
|
|
|