blob: 91f09ec5224411f79ec2dc7abb304eb3ffc0584c (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
|
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE chapter SYSTEM "chapter.dtd">
<chapter>
<header>
<copyright>
<year>2000</year><year>2015</year>
<holder>Ericsson AB. All Rights Reserved.</holder>
</copyright>
<legalnotice>
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
</legalnotice>
<title>Problem Example</title>
<prepared></prepared>
<docno></docno>
<date></date>
<rev></rev>
<file>example.xml</file>
</header>
<section>
<title>Description</title>
<p>A common interoperability situation is when you want to incorporate
a piece of code, solving a complex problem, in your Erlang
program. Suppose for example, that you have the following C
functions that you would like to call from Erlang:</p>
<codeinclude file="complex.c" tag="" type="none"></codeinclude>
<p>The functions are deliberately kept as simple as possible, for
readability reasons.</p>
<p>From an Erlang perspective, it is preferable to be able to call
<c>foo</c> and <c>bar</c> without having to bother about that
they are C functions:</p>
<pre>
% Erlang code
...
Res = complex:foo(X),
...</pre>
<p>Here, the communication with C is hidden in the implementation
of <c>complex.erl</c>.
In the following sections, it is shown how this module can be
implemented using the different interoperability mechanisms.</p>
</section>
</chapter>
|
