Important note: this document is regularly updated (corrections, examples,
bug report, suggestions from customers). Please make sure that you have
downloaded the latest version.
Important note: this document is regularly updated (corrections, examples,
bug report, suggestions from customers). Please make sure that you have
downloaded the latest version.
This document provides an overview of the C-Eiffel Call-In Library (CECIL) as defined in Eiffel: The Language (ETL). The first section adresses how to compile and run a CECIL program. The second part contains a more precise description of the Eiffel types, the protection mechanism as well as how to write and use C externals.
CECIL , designed by ISE, is the C library that permits C and C++ applications (as well as applications written in other languages) to take advantage of almost all Eiffel facilities: create Eiffel objects, apply features to them. The basics of CECIL are described in chapter 24 of the reference book on Eiffel, Eiffel: The Language, which covers interfaces between Eiffel and other languages. Important material can also be found in the ISE manual Eiffel: The Environment and on ISE's FTP server. In particular, the FTP server contains a complete example which you are strongly encouraged to download if you plan to make serious use of CECIL. You can find the examples in
The CECIL documentation, man pages and examples are part of the standard delivery with the ISE Compiler 4.5 and higher.
The present document complement the descriptions of Eiffel: The Language. Note that CECIL has been revised and improved since that book was published, so the explanations below have precedence over those of the book.
This document is intended for both Windows and Unix users. Only a few of the sections, clearly marked, are platform-specific.
Once unzipped, the example directory cited above will yield (apart from a README containing the same material as the present document) two subdirectories: unix-examples and windows-examples. Each contains a full example, adapted to each platform and illustrating the use of CECIL. Please study it carefully and use it as a model. When compiling a CECIL example , you must include `eif_eiffel.h' (for all the cecil features) and `eif_setup.h' (for the run-time initialization and reclaim).
For step 1, note that through CECIL you can use an Eiffel system
compiled in any of the Eiffel compilation modes:
$ applied to melted routineThe solution is simply to refreeze the system.
To do this, include the appropriate features and classes in the visible clause of the Ace file, as in
system system_name root ... default ... cluster ... your_cluster: "..." adapt ... visible CLASS1; CLASS2 creation "other_make" export "other_make", "feat1", "feat2" end end ... Other clusters ... ... endHere all features of CLASS1 are available to the external software; for CLASS2, only other_make (for creation) and feat1 and feat2 (for normal call) are available. For the full set of visible options, see appendix D of Eiffel: The Language. If you omit the clause export , only the features with no export clause in the Eiffel code, will be available. The creation procedure of a visible class is always available See also visible classes
To produce a CECIL library, you must: open a shell (unix) or the MS-DOS prompt (Windows), go to the subdirectory that contains the Makefile, and then type:
On version 4.4 and later, the CECIL library is automatically generated, you do not need to call `nmake cecil' any longer. This will be done when freezing or finalizing.
This generates a CECIL archive whose name derived from the name
<system name> of the Eiffel system, as follows:
You can build a CECIL archive with either the "finalized" C code or "frozen" C code. In the latter case you must copy the "<system name>.melted" file located in $/EIFGEN/W_code/<system name>.melted to the directory from where you intend to execute your C application . Each time you melt the Eiffel system, the <system name>.melted file is updated.
Note: Calling melted routines through the CECIL interface is not supported in the current version - calling a melted routine raises the exception "$ applied to melted routine".
on Unix/linux:
ld -o [name of your CECIL executable] [your C object files and archives] lib<system name>.a -lm
on Windows, with MS VC++:
link [your link flags] -OUT:[name of your cecil executable] [your C object files and archives] lib<system name>.lib [other Windows libraries]
Note:linking with "-lm" is required since the Eiffel 4 run-time uses the standard math libraries.You may need to link with other libraries (for example, on linux: with "-lbsd", in MT mode with "-lpthread" (posix threads) or "-lthread" (solaris)) .
On Windows, you can reuse the .lnk file, which is automatically generated when you freeze or finalize your system: go to the appropriate directory (W_code or
F_code) and locate the file:
<system_name>.lnk
- Copy system_name.lnk into a new file cecil.lnk in the same directory.
- To use the current MS-DOS shell as the default console add the directive "console_application (yes) in your Ace file.
- and replace the line:
by
assuming that the main.obj object file is in the project directory; update the above path if it is in another directory.
Then, link with:
link @cecil.lnk
(in the appropriate directory W_code or F_code)
Notes for compiling
CECIL C files:
The CECIL library is built automatically, which is unfortunately not
the case of the corresponding object files of the cecil program you
wrote.
The C flags to use are usually the same as the ones needed during the
compilation of the generated C-code plus those, which are relevant to your
own C-code.
Typically, you will compile your flags as below:
gcc -c -O -I$EIFFEL4/bench/spec/$PLATFORM/include -I<SOME_INCLUDE_PATH>
-D<SOME_FLAGS> your_file.c
(if your are compiling with gcc on a Solaris).
or
cl -c -nologo -Ox -I<INSTALLATION_DIR>\bench\spec\windows\include
-I<SOME_INCLUDE_PATH> -D<SOME_FLAGS> your_file.c
(if you are using VC on Windows. <INSTALLATION_DIR> is the
installation directory of your Eiffel delivery: C:\Eiffel4, for
example).
For instance, if you want to use the multithreaded facilities of Eiffel, you should define the EIFFEL MT flags.
gcc -c -O -I$EIFFEL4/bench/spec/$PLATFORM/include -DEIF_THREADS -DSOLARIS_THREADS -D_REENTRANT your_file.c
or
cl -c -nologo -DEIF_THREADS -MT -Ox -I<INSTALLATION_DIR>\bench\spec\windows\include your_file.c
You can specify a Makefile in your Ace file, so that your C files will be compiled automatically after the Eiffel compilation and before the final linking. Just add at the end of your Ace file in the external clause:
external:
make: "$PATH_TO_MAKEFILE/your_makefile";
This makefile will be run from the $/EIFGEN/W_code or $/EIFGEN/F_code
directory. You should not give to the CECIL executable the same name as
your system, because it will be replaced by the Eiffel executable when
you run another compilation.
Back to index
In the C file containing the "main" C function, you must add the following
line to include the header file "eif_setup.h" provided with this example:
#include "eif_setup.h" /* Macros EIF_INITIALIZE and EIF_DISPOSE_ALL
*/
#include "eif_eiffel.h" /* Exported functions of the Eiffel run-time
*/
Your "main" function must have the three standard arguments of the C
"main" function" "argc", "argv" and "envp" and include the following macros
that are defined in "eif_setup.h":
main(int argc, char **argv, char **envp)
EIF_INITIALIZE(failure)
/* ...
EIF_DISPOSE_ALL
/* Please, respect this
signature: `argc', `argv' and `envp' are used
* in EIF_INITIALIZE.
*/
{
/* declarations of variables */
/* Initialize the Eiffel run-time. */
* body of your "main" function
*
... */
/* Reclaim the memory allocated by the Eiffel
* run-time. */
}
See the cecil examples on ftp://ftp.eiffel.com/examples/cecil.
Note that the above mentioned macros must imperatively be in the body
of the "main" function for the Eiffel 4 exception handling mechanism to
work correctly.
You also need to add the Eiffel 4 run time directory to the list of
directories in which the C compiler searches for include files. You can
do so by using the "-I" option of your C compiler.
See also Linking the CECIL archive into a program.
An Eiffel INTEGER is an EIF_INTEGER,
An Eiffel CHARACTER is an EIF_CHARACTER,
An Eiffel REAL is an EIF_REAL,
An Eiffel DOUBLE is an EIF_DOUBLE,
Eiffel references (any Eiffel objects, which is not from a basic type)
are EIF_REFERENCE (not protected, and can be moved),
An Eiffel POINTER is an EIF_POINTER,
An Eiffel BOOLEAN is an EIF_BOOLEAN,
An Protected Eiffel objects is an EIF_OBJECT
(do not move, and should be accessed through eif_access.).
Generally, you should use these types when implementing external C
functions bound to be used from Eiffel or when you want to manipulate Eiffel
objects from the C side. EIF_REFERENCE, EIF_OBJECT, EIF_POINTER
all correspond in C to a (char *), but their semantic remains different
in Eiffel.
Example:
c_foo (ptr: POINTER; obj: OBJECT): INTEGER is
external
"C | %"your_file.h%""
alias
"foo"
end
In the C side, The C function `foo' is defined as below:
EIF_INTEGER foo (EIF_POINTER
ptr, EIF_OBJECT obj)
{
/* some code */
}
On the C side, foo is already defined as below:
int foo (void *arg1,
char c, FILE *file)
To match the signature, you must declare it in Eiffel as:
{
/* some code */
}
c_foo (arg1: POINTER; c: CHARACTER; file: POINTER): INTEGER is
To perform the conversion, here is the actual Eiffel types mapping to C types:
An EIF_REFERENCE is an Eiffel reference. It corresponds to an Eiffel object in the Eiffel side. eif_attribute, eif_reference_function , eif_string, eif_wean all return an EIF_REFERENCE. An EIF_REFERENCE can be used "as is" by the Eiffel run-time. eif_attribute, eif_xx_function take EIF_REFERENCE as arguments, never EIF_OBJECT. The return value of a C external is to be an EIF_REFERENCE, if it is not a basic expanded type. To protect an EIF_REFERENCE, use eif_protect.
An EIF_OBJECT is a safe and static indirection to an Eiffel reference. As the GC may move an Eiffel reference, this indirection is updated at every collection so that you do not need to know whether an Eiffel reference has moved or not. You must pass through this indirection to access the Eiffel reference (see eif_access). Not doing it is completely unsafe since an Eiffel reference may be obsolete after a collection. eif_create, eif_adopt, and eif_protect returns an EIF_OBJECT. The argument of a C external (on the C side) , which is not a basic expanded type, is also an EIF_OBJECT . The Eiffel run-time temporarily protects the Eiffel objects that are passed to a C external , that is why the signature of a C external has no EIF_REFERENCE in it, but EIF_OBJECT instead. After the C external call, the run-time unprotects the Eiffel object. If you intend to use in the C side an EIF_OBJECT given by a C external afterwards, you must protect it with eif_adopt. To unprotect an EIF_OBJECT , which is not a C external argument, use eif_wean.
The basic expanded types are INTEGER, REAL, DOUBLE, CHARACTER, BOOLEAN, POINTER. They are passed to C externals by values. There is no need to protect an INTEGER, REAL, DOUBLE, CHARACTER, or a BOOLEAN. When the POINTER is a pointer to an Eiffel object (ex: $my_object ), then the direct Eiffel reference is passed to C, with no protection and this reference may move. Use eif_protect to manually protect it. To unprotect it, call eif_wean
The cecil library provides the user with numorous macros and functions, which relieves the programmer from these kinds of low-level considerations (most of them are declared in $EIFFEL4/bench/spec/$PLATFORM/include/eif_cecil.h).
EIF_REFERENCE eif_access (EIF_OBJECT object) /* Macro */
The GC moves the objects every time it runs a collection cycle. A collection cycle can only occur during Eiffel call. This includes: calls to Eiffel routines, calls to CECIL functions (other than eif_access). Thus, it may be unsafe to access a "raw" reference to an Eiffel object, (of type EIF_REFERENCE) "as is", since the latter can be obsolete after each collection. To avoid this, you must access a direct reference through a "protection", which is a safe, non-moving pointer (of type EIF_OBJECT). Call the macro eif_access as follows: eif_access (protection) , where protection is either a value returned by eif_create, eif_adopt, eif_protect or an Eiffel object, which is an argument of a C external.
Use eif_access to pass an Eiffel object to an Eiffel routine or to return the value of a C external. It is also unsafe to pass a direct Eiffel reference (EIF_REFERENCE) to a C function, which is not an Eiffel routine. Pass a protected indirection instead (EIF_OBJECT). However, if you still intend to pass a direct reference, be very careful and make sure that you do not perform any Eiffel call after passing the reference to the C function and before reading it.
For example, in the following external:
c_foo (ptr: POINTER; obj: OBJECT): INTEGER is
external
"C | %"your_file.h%""
alias
"foo"
end
the Eiffel run-time will protect obj ,which can asynchronously move, and give a static and safe indirection to C.
Here is an example of how accessing obj: OBJECT:
EIF_INTEGER foo (EIF_POINTER ptr, EIF_OBJECT obj);
{
/* Print the Eiffel object
`obj', with the feature `print'
* from GENERAL.
(do not forget to put `visible' the class
* GENERAL in the
Ace.ace file.
*/
EIF_PROCEDURE ep;
EIF_TYPE_ID tid;
tid = eif_type_id ("GENERAL");
ep = eif_procedure ("print",
tid);
(ep) (eif_access(obj),eif_access(obj));
}
NB: The first argument of (ep) is the target of the function (the eiffel object to which you want to apply the Eiffel feature (ep)) and the second argument corresponds to the first argument of `print'. Note that any Eiffel objects could have been the 1st argument of (ep) since all of them inherit from GENERAL.
Important rules when using eif_access:
EIF_REFERENCE e_ref = eif_access (obj);
...
(ep) (e_ref, e_ref);
because e_ref is the direct reference to the Eiffel object when calling
eif_access().
There
is not guarantee that it will still be valid when the call to
(ep)
is done: meanwhile, e_ref may have been moved by the GC.
(ep) (eif_access (a), eif_string ("Hello world"));
/* eif_string is a macro returning
a direct reference to an Eiffel string,
* which corresponds
to the C string passed as its argument.
*/
Nothing guarantees that the direct reference returned by `eif_access
(a)' will be still valid when executing (ep): it may be obsolete
after the Eiffel call eif_string ("Hello world"), which may invoke a collection
cycle.
The correct code is
EIF_REFERENCE my_string;
/* some code */
my_string = eif_string
("Hello world");
(ep) (eif_access (a),
my_string);
In this case, you do not need to protect `my_string' since the GC is not likely to be triggered after the call to eif_string and before `my_string' is given as argument in (ep) . A collection is triggered only during Eiffel calls. If an Eiffel call had been performed, you would have had to use `eif_protect' (see paragraph 3.2):
EIF_REFERENCE my_string;
EIF_OBJECT i_my_string;
/* some code */
my_string = eif_string ("Hello world");
i_my_string = eif_protect (my_string); /* Protect
`my_string'. */
/* Some eiffel calls
*/
(ep) (eif_access (a), eif_access (i_my_string));
eif_wean (i_my_string); /* Release protection.
*/
See also eif_protect.
EIF_OBJECT eif_adopt (EIF_OBJECT object)
When passing Eiffel objects to C, you may need to keep a reference to them after the C external is called. Since the Eiffel run-time automatically unprotects the Eiffel objects references passed to a C external after execution. If one of the Eiffel objects is not referenced any longer from Eiffel, then the garbage collector will collect it because it is not aware that you may still need to reference this object from the C side.
Called within a C external, the function eif_adopt creates a user protection for the Eiffel object object passed to C (object is a C external argument). This way, the GC cannot collect the Eiffel reference returned by eif_access(object) when the C external returned. It tells the GC to keep artificially a reference to this Eiffel reference from C. It returns the new indirection pointer (say returned_value) that must be used afterwards to access this direct Eiffel reference with eif_access (return_value). It is important to note that eif_adopt already takes an indirection pointer as unique argument . This is a temporary protection pointer: you can access the direct Eiffel reference with eif_access (object). only within the code of the C external. When the C external returned, eif_access (object) is NULL but eif_access (returned_value) remains valid until you release it with `eif_wean'.
See also eif_access, eif_protect, eif_create, More about Eiffel types.
Example:
In Eiffel:
c_foo (ptr: POINTER; obj: OBJECT): INTEGER is
external
"C | %"your_file.h%""
alias
"foo"
end
c_display_and_release_obj is
external
"C | %"your_file.h%""
alias
"display_and_release_obj"
end
On the C side:
EIF_OBJECT my_obj; /* Protection of the object of type OBJECT. */
EIF_INTEGER foo (EIF_POINTER ptr, EIF_OBJECT obj)
{
my_obj = eif_adopt (obj); /* Keeping a reference on it for
* for later use.
*/
/* some code */
}
void display_and_release_obj (void)
{
/* Display global object. */
EIF_PROCEDURE ep;
EIF_TYPE_ID tid;
tid = eif_type_id ("OBJECT");
ep = eif_procedure ("print", tid);
(ep) (eif_access(my_obj),eif_access(my_obj)); /* Print global object.*/
eif_wean (my_obj); /* Remove the protection on global object.*/
}
Between the call of `c_foo' and `c_display_obj', the global object (eif_access (my_obj)) may not be referenced from Eiffel any longer. To prevent the GC from collecting it before the call to `c_display_and_release_obj', you must protect it with `eif_adopt' in the C function `foo'.
EIF_OBJECT eif_create ( EIF_TYPE_ID type_id)
All CECIL calls are not completed using C external. It is possible to create and manipulate Eiffel objects from a C program and still reap benefits from the garbage collector and design by contract methodology provided by Eiffel (see also How to run a CECIL program ). This function does not call any creation procedure.
The CECIL function eif_create takes a type identifier type_id as argument (generally returned by eif_type_id). It returns a static indirection pointer which is to be used afterwards to access the newly created Eiffel object with eif_access (returned_value) where returned_value is the value returned by eif_create . This means that when creating an eiffel object from C, the eiffel object is automatically protected: there is no need to call eif_adopt or eif_protect on it. This function does not call any creation procedure. To do so, you need to explicitly call it with eif_procedure. The garbage collector will not collect the newly created object until you call eif_wean on it.
See also More about Eiffel types.
Example:
Creating an object of type "OBJECT":
#include eif_setup.h" /* for EIF_INITIALIZE and EIF_DISPOSE_ALL */
#include "eif_eiffel.h" /* for other exported routines from the
Eiffel run-time */
main (int argc,char **argv,char **envp)
{
EIF_TYPE_ID tid;
EIF_OBJECT my_obj;
EIF_INITIALIZE(failure) /* Initialization of Eiffel run-time.
* This is to be done before any CECIL call.
*/
tid = eif_type_id ("OBJECT");
if (tid == EIF_NO_TYPE)
eif_panic ("No type id.");
my_obj = eif_create (tid); /* Create eiffel object, returns an indirection.
*/
/* some code */
eif_wean (my_obj); /* We do not need it any more. */
EIF_DISPOSE_ALL /* Reclaim memory allocated by Eiffel run-time. */
}
Note: `eif_create' does not call any creation procedure. It just
allocates
memory and initializes an object.
This function is used to tell explicitely the GC that you want to keep a reference to an eiffel object from the C. It returns a static indirection pointer which is to be used afterwards to access the direct Eiffel reference object with eif_access (returned_value) where returned_value is the value returned by eif_protect . With this call, the GC artificially references object, so that it cannot collect it. It is unsafe to access directly (i.e without using eif_access) the Eiffel reference object, which may be obsolete after any collection cycle (the GC moves the objects). Ignore this rule, if you are sure that there is no Eiffel call after you pass the direct Eiffel reference to a C function and before you read it.
To release this articifial reference, call eif_wean (returned_value)
eif_protect is to be called on an EIF_REFERENCE returned by eif_attribute,
eif_string, or the returned value of eif_reference_function.
See also
Example: Assume that you want to access an attribute `tab' of type ARRAY [INTEGER] in the class OBJECT.
#include eif_setup.h"
#include "eif_eiffel.h"
main (int argc,char **argv,char **envp)
{
EIF_TYPE_ID tid;
EIF_OBJECT my_obj;
EIF_PROCEDURE emake; /* Creation procedure of "OBJECT". */
EIF_REFERENCE tab; /* direct reference to `tab' from "OBJECT". */
EIF_OBJECT i_tab; /* Protected indirection to `tab'. */
EIF_INITIALIZE(failure)
tid = eif_type_id ("OBJECT");
if (tid == EIF_NO_TYPE)
eif_panic ("No type Id.");
my_obj = eif_create (tid);
emake = eif_procedure ("make", tid); /* On the eiffel side: make
is do ... end.. */
(emake) (eif_access (my_obj)); /* Call `make' on `eif_access(my_obj)'.*/
tab = eif_attribute( eif_access (my_obj), "tab", EIF_REFERENCE, NULL);
/* Return the attribute `tab' of type EIF_REFERENCE
* of the object `eif_access (my_obj)'.
*/
i_tab = eif_protect (tab); /* Here, protect `tab'. */
/* some code */
eif_wean (my_obj);
eif_wean (i_tab); /* We do not need it any more. */
EIF_DISPOSE_ALL /* Reclaim memory allocated by Eiffel run-time. */
}
Note: Although you must protect Eiffel references returned by eif_attribute. You must not protect attributes of basic types - they are not Eiffel references and not supposed to move.
EIF_TYPE_ID eif_type_id (char *type_string)
Returns the type identifier corresponding to the type described in type_string. If the type does not exists , is not visible or an instance of it is not declared in the root class (see visible classes), it returns EIF_NO_TYPE.
COMPATIBILITY:
Example: type_id of STD_FILES so as to call 'put_string'.
EIF_PROCEDURE p_put_string;
/* 'put_string' from STD_FILES. */
EIF_TYPE_ID tid;
EIF_REFERENCE_FUNCTION fn_io;
/* once function `io' from GENERAL (and STD_FILES by inheritance).
*/
EIF_REFERENCE o_io; /* Eiffel
object `io' returned by once function*/
EIF_REFERENCE o_str;
/* Eiffel string */
EIF_OBJECT i_io, i_str; /*
safe indirection pointers to ``io' and Eiffel string.
*/
tid = eif_type_id ("STD_FILES");
if (tid == EIF_NO_TYPE)
eif_panic ("Type not
in system.");
fn_io = eif_reference_function ("io", tid);
o_io = (fn_io) (root_obj);
/* `root_obj' is the root object of the CECIL system
* automatically initialized in EIF_INITIALIZED
* if it does not exists */
i_io = eif_protect (o_io);
/* Protect `io' . */
o_str = eif_string ("Hello World");
/* Create Eiffel string */
i_str = eif_protect (o_str);
/* Protect Eiffel string. */
p_put_string = eif_procedure ("put_string", tid);
if (p_put_string == (EIF_PROCEDURE) 0) /* No routine found. */
eif_panic ("put_string not visible"); /* Raised if "visible exception" disabled. */
(p_put_string) (eif_access (i_io), eif_access
(i_str));
eif_type_id is also used for returning the type identifier of generic types but you need to specify the generic parameter, otherwise it returns EIF_NO_TYPE.
Example:
EIF_PROCEDURE p_make;
/* 'make' from ARRAY [INTEGER] . */
EIF_TYPE_ID tid;
tid = eif_type_id ("ARRAY[INTEGER]");
p_make = eif_procedure ("make", tid);
See also eif_procedure, eif_xx_function
void eif_panic(char *msg)
#include "eif_threads.h"
void eif_thr_panic (char *msg)
Raise an Eiffel panic with Eiffel exception trace with message msg . In MT mode, use eif_thr_panic instead.
EIF_REFERENCE eif_wean(EIF_OBJECT object)
Tells the GC to remove the artificial reference to the nested
Eiffel reference returned by eif_access (object). Then, the GC will be able collect this nested object,
as soon as it is not referenced from Eiffel any longer.
Note that object must be previously created with eif_adopt,
eif_protect or eif_create.
eif_wean (object) returns an Eiffel reference, which corresponds to eif_access (object). After a call to
eif_wean (object), eif_access (object) is NULL, which does not mean that the nested Eiffel object is Void, but that the indirection pointer does not reference it any longer. It is possible to reuse
object later on.
Calling eif_wean (external_argument) where external_argument is an Eiffel object given by a C external can cause erratic behaviors. Indeed,
external_argument is an indirection pointer, which is automatically deleted after the external call (not the nested Eiffel object), deleting it prematuraly can corrupt the indirection pointers stack.
See also eif_access.
Example: C external returning an Eiffel string.
In Eiffel:
foo : STRING is
external
"C
| %"a file.h%""
end
In C:
EIF_REFERENCE foo () {
EIF_REFERENCE str;
EIF_OBJECT i_str;
str = eif_string ("Hello world");
i_str = eif_protect(str);
/* Some operations on
`i_str' */
return eif_wean (i_str);
/* Returns direct reference to the Eiffel string.
* No need to keep an extra reference from the C. */
}
EIFFEL_TYPE eif_attribute (EIF_REFERENCE object, char *name, EIFFEL_TYPE, int *status)
Return the attribute of an Eiffel object.
The `eif_attribute' macro returns the attribute of object of name name, which is of type EIFFEL_TYPE.
EIFFEL_TYPE is the type of the Eiffel attribute. It can be: EIF_INTEGER, EIF_POINTER, EIF_CHARACTER, EIF_BOOLEAN, EIF_DOUBLE, EIF_REAL or EIF_REFERENCE.
If status is NULL then no status is set. Otherwise the status of the function is put in
*status:
*status = EIF_NO_ATTRIBUTE => no attribute found.
*status = EIF_CECIL_OK => attribute found.
*status = EIF_CECIL_ERROR => an undefined error occured, object may be invalid.
If the visible exception is enabled, then a visible exception is raised upon failure (EIF_NO_ATTRIBUTE, EIF_CECIL_ERROR).
RETURN VALUE:
COMPATIBILITY:
NOTE:
OTHER:
See also eif_procedure, eif_xx_function.
EIF_PROCEDURE eif_procedure
(char *rout_name, EIF_TYPE_ID type_id)
EIF_REFERENCE_FUNCTION eif_reference_function
(char *rout_name, EIF_TYPE_ID type_id)
EIF_INTEGER_FUNCTION eif_integer_function
(char *rout_name, EIF_TYPE_ID type_id)
EIF_CHARACTER_FUNCTION eif_character_function
(char *rout_name, EIF_TYPE_ID type_id)
EIF_REAL_FUNCTION eif_real_function
(char *rout_name, EIF_TYPE_ID type_id)
EIF_DOUBLE_FUNCTION eif_double_function
(char *rput_name, EIF_TYPE_ID type_id)
EIF_BIT_FUNCTION eif_bit_function
(char *rout_name, EIF_TYPE_ID type_id)
EIF_BOOLEAN_FUNCTION eif_boolean_function
(char *rout_name, EIF_TYPE_ID type_id)
EIF_POINTER_FUNCTION eif_pointer_function
(char *rout_name, EIF_TYPE_ID type_id)
Returns the address of the Eiffel routine by giving its name rout_name and the type id type_id of the class, in which it is declared. Returns a NULL pointer or raises a visible exception (if enabled) when there is no corresponding routine with name rout_name or the routine is not visible. The first argument of an Eiffel routine has to be the target of the Eiffel routine.
The Eiffel object returned by an Eiffel function must be protected afterwards with 'eif_protect' (this only applies for functions, which address is returned by `eif_reference_function' since the other function types returns basic types, which are not Eiffel objects).
NOTES:
Be sure that the Eiffel routine is not a C External. In this case, you must call directly the C External instead of its Eiffel wrapper.
See also Declaring routines taking real as argument, Cast of the Eiffel routines in C, Bad macros in eif_cecil.h.
void eif_enable_visible_exception
()
void eif_disable_visible_exception
()
Respectively,
enables and disables the visible exception. See visible
exception
By default, the visible exception is disabled (since v4.5).
EIF_REFERENCE eif_string (char *string) /* Macro */
Returns the direct reference to an Eiffel string by giving the corresponding C string string . The result of eif_string does not reference the C string passed as argument: it copies it, before creating the Eiffel string.
NOTE:
COMPATIBILITY:
int eif_attribute_type (char *attr_name, EIF_TYPE_ID tid)
#define EIF_REFERENCE_TYPE
1
#define EIF_CHARACTER_TYPE
2
#define EIF_BOOLEAN_TYPE
3
#define EIF_INTEGER_TYPE
4
#define EIF_REAL_TYPE
5
#define EIF_DOUBLE_TYPE
6
#define EIF_EXPANDED_TYPE
7
#define EIF_BIT_TYPE
8
#define EIF_POINTER_TYPE
0
#define EIF_NO_TYPE
(-1)
Returns the type of the attribute described by its name attr_name and the type identifier of the class where it is defined tid. The return type is an int (see above for correspondances). In case of failure, EIF_NO_TYPE is returned - not such given attribute name, routine name instead of attribute name, or so on.
Example: Get the type of count from STRING
int i;
i = eif_attribute_type ("count", eif_type_id ("STRING");
printf ("type is %d\n"); /*
Should be EIF_INTEGER_TYPE since it returns an Eiffel Integer */
OTHER:
See also:
char *eif_name (EIF_TYPE_ID tid)
Returns the corresponding name (C string) of the Eiffel class, given a type identifier type_id. If the type identifier is a generic type identifier, no generic parameter type is given. Returns NULL if an invalid type idientifer is given.
Example:
printf ("the class name with type id 1 is %s\n", eif_name (1); /* Should print "PLATFORM" on most compiler versions*/
COMPATIBILITY:
See also eif_type, eif_type_id
EIF_TYPE_ID eif_type (EIF_OBJECT object)
EIF_TYPE_ID eif_type_by_reference (EIF_REFERENCE reference)
eif_type returns the type identifier, given an indirection pointer to an Eiffel object.
eif_type_by_reference returns the type identifier, given the direct reference to an Eiffel object reference.
COMPATIBILITY:
Not on ISE Eiffel compilers prior to 4.5. However, its definition is available at ftp://ftp.eiffel.com/pub/examples/cecil/cecil/C2array/array-opt . eif_array is an EIF_REFERENCE, c_array is a C array of type (type *), nelts is the number of elements in the array.
Example: call to put (r: REAL ; index: INTEGER) from ARRAY [REAL])
typedef void (*EIF_PROCEDURE_REAL_INTEGER)(EIF_REFERENCE, EIF_REAL, EIF_INTEGER);
EIF_PROC_REAL_INTEGER eput;
/* some code */
eput = (EIF_PROCEDURE_REAL_INTEGER) eif_procedure ("put", eif_type_id ("ARRAY
[REAL]"));
These typedefs do not perform the type checking of the arguments. The typedefs only cast the result of the Eiffel routine (void if it is an Eiffel procedure). For more information on the previous definitions, see their definitions in $EIFFEL4/bench/spec/$PLATFORM/include/eif_cecil.h.
CECIL can not generate relevant typedefs for every type of routine that is exported to C through CECIL. Consequently, you must define manually the typedefs to properly cast the pointer type to the Eiffel routine. This way, during compilation, a warning or an error is raised if arguments with incorrect types are passed to the Eiffel routine.
Example:
Let the Eiffel function `foo' :
foo (c: CHARACTER; a: ARRAY [INTEGER]): POINTER is
typedef EIF_POINTER (*EIF_FOO_TYPE)(EIF_REFERENCE /* Current object */,
EIF_REFERENCE /* 2d argument */);
NOTE:
You cannot use the Eiffel routine types for the routines, which are Eiffel External routines. The cast would be incorrect since these routines do not take an EIF_REFERENCE as first argument, but the actual first argument of the Eiffel signature. It is recommended to use directly the C function instead.
- Using a non-generic type, declare:
dummy: SIMPLE_TYPE
in your root class.
a_cluster: "A_PATH"
visible
SIMPLE_TYPE
end
end;
in your Ace file.
- Using Generic types , declare for example:
dummy1: GEN_TYPE [INTEGER]
dummy2: GEN_TYPE [OTHER_TYPE]
in the root class.
and
an_other_cluster: "AN_OTHER_PATH"
visible
GEN_TYPE
-- Do not specify any generic parameter.
end
end;
in your Ace file.
This is necessary to tell the compiler to generate the C code corresponding to GEN_TYPE[INTEGER] or GEN_TYPE[OTHER_TYPE] and make it available to CECIL. Otherwise, eif_type_id will returns EIF_NO_TYPE, and eif_procedure/eif_function_xx will return a NULL pointer or raise a visible exception.
You can disable this exception by calling eif_disable_visible_exception. You can also enable it with eif_enable_visible_exception.
If you try to call eif_procedure or eif_xx_function to get the pointer on a non visible routine, they will return a NULL pointer.
Exporting features to CECIL, overriding the export clause in the Ace file:
Example: export the feature foo from class A which has an export clause.
In Eiffel:
feature {B,C} -- Only exported
to classes B and C
foo is
do
...
end
In the Ace file:
....
visible
A
export
"make", -- creation procedure
"foo"
end
end
...
In this case, only foo and make are exported to CECIL.
All other features from class A are no longer available. See also
ETL Part E, appendice D and bug in export clause.
The name of the features to export should be put between " " to avoid any confusion with Lace keywords.
By default, the creation procedure(s) of a visible class is/are exported and visible in CECIL. However, if the creation procedure is defined in a parent and has an export clause in the Eiffel code, you must explicitely export it to CECIL in the Ace file.
#define eif_fn_pointer eifpointer /* Use `eif_pointer_function' instead */
#define eif_fn_pointer eifptr /* Use `eif_pointer_function' instead */
and the lines: