Whitespace cleanup
This commit is contained in:
parent
064f18131d
commit
13894f803b
1 changed files with 155 additions and 153 deletions
|
|
@ -4,8 +4,8 @@
|
||||||
<title>SWIG and Ocaml</title>
|
<title>SWIG and Ocaml</title>
|
||||||
<link rel="stylesheet" type="text/css" href="style.css">
|
<link rel="stylesheet" type="text/css" href="style.css">
|
||||||
</head>
|
</head>
|
||||||
|
|
||||||
<body bgcolor="#ffffff">
|
<body bgcolor="#ffffff">
|
||||||
<a name="n1"></a>
|
|
||||||
<H1><a name="Ocaml"></a>31 SWIG and Ocaml</H1>
|
<H1><a name="Ocaml"></a>31 SWIG and Ocaml</H1>
|
||||||
<!-- INDEX -->
|
<!-- INDEX -->
|
||||||
<div class="sectiontoc">
|
<div class="sectiontoc">
|
||||||
|
|
@ -59,8 +59,11 @@
|
||||||
|
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
This chapter describes SWIG's
|
This chapter describes SWIG's support of Ocaml.
|
||||||
support of Ocaml. Ocaml is a relatively recent addition to the ML family,
|
</p>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
Ocaml is a relatively recent addition to the ML family,
|
||||||
and is a recent addition to SWIG. It's the second compiled, typed
|
and is a recent addition to SWIG. It's the second compiled, typed
|
||||||
language to be added. Ocaml has widely acknowledged benefits for engineers,
|
language to be added. Ocaml has widely acknowledged benefits for engineers,
|
||||||
mostly derived from a sophisticated type system, compile-time checking
|
mostly derived from a sophisticated type system, compile-time checking
|
||||||
|
|
@ -92,9 +95,8 @@ examples and test-suite which come with SWIG. You can do this by running
|
||||||
<tt>make check</tt> from the SWIG root directory after installing SWIG.
|
<tt>make check</tt> from the SWIG root directory after installing SWIG.
|
||||||
The Ocaml module has been tested using the system's dynamic linking (the
|
The Ocaml module has been tested using the system's dynamic linking (the
|
||||||
usual -lxxx against libxxx.so, as well as with Gerd Stolpmann's
|
usual -lxxx against libxxx.so, as well as with Gerd Stolpmann's
|
||||||
<a
|
<a href="http://download.camlcity.org/download/">Dl package</a>.
|
||||||
href="http://download.camlcity.org/download/">Dl package
|
The ocaml_dynamic and ocaml_dynamic_cpp targets in the
|
||||||
</a>. The ocaml_dynamic and ocaml_dynamic_cpp targets in the
|
|
||||||
file Examples/Makefile illustrate how to compile and link SWIG modules that
|
file Examples/Makefile illustrate how to compile and link SWIG modules that
|
||||||
will be loaded dynamically. This has only been tested on Linux so far.
|
will be loaded dynamically. This has only been tested on Linux so far.
|
||||||
</p>
|
</p>
|
||||||
|
|
@ -134,8 +136,7 @@ the type of each SWIG'ed module's c_obj is derived from Swig.c_obj_t. This
|
||||||
also allows SWIG to acquire new conversions painlessly, as well as giving
|
also allows SWIG to acquire new conversions painlessly, as well as giving
|
||||||
the user more freedom with respect to custom typing.
|
the user more freedom with respect to custom typing.
|
||||||
|
|
||||||
Use <tt>ocamlc</tt> or <tt>ocamlopt</tt> to compile your
|
Use <tt>ocamlc</tt> or <tt>ocamlopt</tt> to compile your SWIG interface like:
|
||||||
SWIG interface like:
|
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code">
|
<div class="code">
|
||||||
|
|
@ -154,7 +155,9 @@ the user more freedom with respect to custom typing.
|
||||||
|
|
||||||
<div class="code">
|
<div class="code">
|
||||||
<pre>
|
<pre>
|
||||||
% cp example_wrap.cxx example_wrap.cxx.c<br>% ocamlc -c ... -ccopt -xc++ example_wrap.cxx.c<br>% ...<br>
|
% cp example_wrap.cxx example_wrap.cxx.c
|
||||||
|
% ocamlc -c ... -ccopt -xc++ example_wrap.cxx.c
|
||||||
|
% ...
|
||||||
</pre>
|
</pre>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
|
@ -273,7 +276,7 @@ In the code as seen by the typemap
|
||||||
writer, there is a value, swig_result, that always contains the
|
writer, there is a value, swig_result, that always contains the
|
||||||
current return data. It is a list, and must be appended with the
|
current return data. It is a list, and must be appended with the
|
||||||
caml_list_append function, or with functions and macros provided by
|
caml_list_append function, or with functions and macros provided by
|
||||||
objective caml.<br>
|
objective caml.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<div class="code"><pre>
|
<div class="code"><pre>
|
||||||
|
|
@ -303,11 +306,10 @@ type c_obj =
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<ul>
|
<ul>
|
||||||
<li>caml_ptr_val receives a c_obj and returns a void *. This
|
<li>caml_ptr_val receives a c_obj and returns a void *. This
|
||||||
should be used for all pointer purposes.</li>
|
should be used for all pointer purposes.</li>
|
||||||
<li>caml_long_val receives a c_obj and returns a long. This
|
<li>caml_long_val receives a c_obj and returns a long. This
|
||||||
should be used for most integral purposes.<br>
|
should be used for most integral purposes.</li>
|
||||||
</li>
|
|
||||||
<li>caml_val_ptr receives a void * and returns a c_obj.</li>
|
<li>caml_val_ptr receives a void * and returns a c_obj.</li>
|
||||||
<li>caml_val_bool receives a C int and returns a c_obj representing
|
<li>caml_val_bool receives a C int and returns a c_obj representing
|
||||||
its bool value.</li>
|
its bool value.</li>
|
||||||
|
|
@ -318,26 +320,25 @@ appropriate C value and returns a c_obj representing it.</li>
|
||||||
a string value.</li>
|
a string value.</li>
|
||||||
<li>caml_val_obj receives a void * and an object type and returns
|
<li>caml_val_obj receives a void * and an object type and returns
|
||||||
a C_obj, which contains a closure giving method access.</li>
|
a C_obj, which contains a closure giving method access.</li>
|
||||||
|
|
||||||
</ul>
|
</ul>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
Because of this style, a typemap can return any kind of value it
|
Because of this style, a typemap can return any kind of value it
|
||||||
wants from a function. This enables out typemaps and inout typemaps
|
wants from a function. This enables out typemaps and inout typemaps
|
||||||
to work well. The one thing to remember about outputting values
|
to work well. The one thing to remember about outputting values
|
||||||
is that you must append them to the return list with swig_result = caml_list_append(swig_result,v).
|
is that you must append them to the return list with swig_result = caml_list_append(swig_result,v).
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
This function will return a new list that has your element
|
This function will return a new list that has your element
|
||||||
appended. Upon return to caml space, the fnhelper function
|
appended. Upon return to caml space, the fnhelper function
|
||||||
beautifies the result. A list containing a single item degrades to
|
beautifies the result. A list containing a single item degrades to
|
||||||
only that item (i.e. [ C_int 3 ] -> C_int 3), and a list
|
only that item (i.e. [ C_int 3 ] -> C_int 3), and a list
|
||||||
containing more than one item is wrapped in C_list (i.e. [ C_char
|
containing more than one item is wrapped in C_list (i.e. [ C_char
|
||||||
'a' ; C_char 'b' -> C_list [ C_char 'a' ; C_char b
|
'a' ; C_char 'b' -> C_list [ C_char 'a' ; C_char b
|
||||||
]). This is in order to make return values easier to handle
|
]). This is in order to make return values easier to handle
|
||||||
when functions have only one return value, such as constructors,
|
when functions have only one return value, such as constructors,
|
||||||
and operators. In addition, string, pointer, and object
|
and operators. In addition, string, pointer, and object
|
||||||
values are interchangeable with respect to caml_ptr_val, so you can
|
values are interchangeable with respect to caml_ptr_val, so you can
|
||||||
allocate memory as caml strings and still use the resulting
|
allocate memory as caml strings and still use the resulting
|
||||||
pointers for C purposes, even using them to construct simple objects
|
pointers for C purposes, even using them to construct simple objects
|
||||||
|
|
@ -348,9 +349,10 @@ is that you must append them to the return list with swig_result = caml_list_a
|
||||||
The wild card type that you can use in lots of different ways is
|
The wild card type that you can use in lots of different ways is
|
||||||
C_obj. It allows you to wrap any type of thing you like as an
|
C_obj. It allows you to wrap any type of thing you like as an
|
||||||
object using the same mechanism that the ocaml module
|
object using the same mechanism that the ocaml module
|
||||||
does. When evaluated in caml_ptr_val, the returned value is
|
does. When evaluated in caml_ptr_val, the returned value is
|
||||||
the result of a call to the object's "&" operator, taken as a pointer.
|
the result of a call to the object's "&" operator, taken as a pointer.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
You should only construct values using objective caml, or using the
|
You should only construct values using objective caml, or using the
|
||||||
functions caml_val_* functions provided as static functions to a SWIG
|
functions caml_val_* functions provided as static functions to a SWIG
|
||||||
|
|
@ -399,11 +401,11 @@ it describes the output SWIG will generate for class definitions.
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
SWIG will wrap enumerations as polymorphic variants in the output
|
SWIG will wrap enumerations as polymorphic variants in the output
|
||||||
Ocaml code, as above in C_enum. In order to support all
|
Ocaml code, as above in C_enum. In order to support all
|
||||||
C++-style uses of enums, the function int_to_enum and enum_to_int are
|
C++-style uses of enums, the function int_to_enum and enum_to_int are
|
||||||
provided for ocaml code to produce and consume these values as
|
provided for ocaml code to produce and consume these values as
|
||||||
integers. Other than that, correct uses of enums will not have
|
integers. Other than that, correct uses of enums will not have
|
||||||
a problem. Since enum labels may overlap between enums, the
|
a problem. Since enum labels may overlap between enums, the
|
||||||
enum_to_int and int_to_enum functions take an enum type label as an
|
enum_to_int and int_to_enum functions take an enum type label as an
|
||||||
argument. Example:
|
argument. Example:
|
||||||
</p>
|
</p>
|
||||||
|
|
@ -577,12 +579,12 @@ void printfloats( float *tab, int len );
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
C++ classes, along with structs and unions are represented by C_obj
|
C++ classes, along with structs and unions are represented by C_obj
|
||||||
(string -> c_obj -> c_obj) wrapped closures. These objects
|
(string -> c_obj -> c_obj) wrapped closures. These objects
|
||||||
contain a method list, and a type, which allow them to be used like
|
contain a method list, and a type, which allow them to be used like
|
||||||
C++ objects. When passed into typemaps that use pointers, they
|
C++ objects. When passed into typemaps that use pointers, they
|
||||||
degrade to pointers through their "&" method. Every method
|
degrade to pointers through their "&" method. Every method
|
||||||
an object has is represented as a string in the object's method table,
|
an object has is represented as a string in the object's method table,
|
||||||
and each method table exists in memory only once. In addition
|
and each method table exists in memory only once. In addition
|
||||||
to any other operators an object might have, certain builtin ones are
|
to any other operators an object might have, certain builtin ones are
|
||||||
provided by SWIG: (all of these take no arguments (C_void))
|
provided by SWIG: (all of these take no arguments (C_void))
|
||||||
</p>
|
</p>
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue