mirrors/eiffel-org
1
0
Fork 0
mirror of https://github.com/EiffelSoftware/eiffel-org.git synced 2025-12-06 14:52:03 +01:00
Code Issues Packages Projects Releases Wiki Activity

Author:halw

Browse Source 
Date:2008-12-01T22:45:08.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@112 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
halw
2008-12-01 22:45:08 +00:00
parent 7312cec21e
commit bba0936e07
11 changed files with 282 additions and 252 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/index.wiki
View File

@@ -1,4 +1,4 @@
[[Property:title|Software Installation for EiffelStudio 6.2]]
[[Property:title|Software Installation for EiffelStudio 6.3]]
[[Property:link_title|Software Installation for EiffelStudio]]
[[Property:weight|0]]
[[Property:uuid|b92cecd4-4a0c-e2f5-b63e-5d01d39ba990]]

30
documentation/current/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/once-features-multithreaded-mode.wiki
View File

@@ -22,25 +22,25 @@ Moreover, an Eiffel programmer should be able to have an alternative between a o
Here is what you will do to implement a once per process feature:
<code>
class
TEST_ONCE_PER_PROCESS
TEST_ONCE_PER_PROCESS
feature -- Access
object_per_thread: OBJECT is
-- Once per thread.
once
create Result.make
end
object_per_thread: OBJECT
-- Once per thread.
once
create Result.make
end
object_per_process: OBJECT is
-- New 'object' (once per process)
-- that could be shared between threads
-- without reinitializing it.
indexing
once_status: global
once
create Result.make
end
object_per_process: OBJECT
-- New 'object' (once per process)
-- that could be shared between threads
-- without reinitializing it.
indexing
once_status: global
once
create Result.make
end
end -- class TEST_ONCE_PER_PROCESS
</code>

116
documentation/current/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/thread-library-overview.wiki
View File

@@ -9,23 +9,24 @@ The class of the thread object you want to create should inherit the <eiffel>THR
Your thread is represented by a class which inherits from <eiffel>THREAD</eiffel> (deferred class). <br/>
<code>
class
MY_THREAD
class
MY_THREAD
inherit
THREAD
...
inherit
THREAD
...
feature
feature
execute is
-- define the deferred feature from THREAD.
do
...
end
...
execute
-- define the deferred feature from THREAD.
do
...
end
end -- class MY_THREAD
...
end -- class MY_THREAD
</code>
@@ -33,11 +34,13 @@ Creating a thread is like creating an Eiffel object:
<code>
my_thread: MY_THREAD
-- MY_THREAD inherits from THREAD and defines
-- the deferred procedure `execute'
my_thread: MY_THREAD
-- MY_THREAD inherits from THREAD and defines
-- the deferred procedure `execute'
create my_thread
...
create my_thread
</code>
@@ -45,7 +48,8 @@ Creating a thread is like creating an Eiffel object:
To run the thread, use the feature <eiffel>launch</eiffel> from <eiffel>THREAD</eiffel>. }}
<code> my_thread.launch</code>
<code>
my_thread.launch</code>
On the Eiffel side, the procedure <eiffel>execute</eiffel> will be launched. This procedures deferred in class <eiffel>THREAD</eiffel>, you have to define it in <eiffel>MY_THREAD</eiffel>.
@@ -66,22 +70,28 @@ The implementation of the class <eiffel>MUTEX</eiffel> is mapped on the C standa
* Declaration of the mutex:
<code> my_mutex: MUTEX</code>
<code>
my_mutex: MUTEX</code>
* Creation of mutex:
<code> create my_mutex.make</code>
<code>
create my_mutex.make</code>
* Locking the mutex:
<code> my_mutex.lock</code>
<code>
my_mutex.lock</code>
* Unlocking the mutex:
<code> my_mutex.unlock</code>
<code>
my_mutex.unlock</code>
* <eiffel>try_lock</eiffel>: if it is not locked yet, lock the mutex and return True, otherwise it returns False.
<code> my_mutex.try_lock</code>
<code>
my_mutex.try_lock</code>
* Is my mutex initialized?
<code> my_mutex.is_set</code>
<code>
my_mutex.is_set</code>
{{note|on Windows: The <eiffel>MUTEX</eiffel> objects on Windows are recursive while they are not on Unix. A recursive mutex can be locked twice by the same thread. }}
@@ -96,19 +106,24 @@ Like <eiffel>MUTEX</eiffel>, the features of this class are mapped on the C thre
* Declaration of the semaphore :
<code> my_sem: SEMAPHORE</code>
<code>
my_sem: SEMAPHORE</code>
Creation of semaphore: initialize semaphore with nb_tokens, it requires nb_tokens > = 0
<code> create my_sem.make (nb_tokens)</code>
<code>
create my_sem.make (nb_tokens)</code>
* Wait for a token:
<code> my_sem.wait</code>
<code>
my_sem.wait</code>
* Give back a token:
<code> my_sem.post</code>
<code>
my_sem.post</code>
* <eiffel>try_wait</eiffel>, similar to try_lock from <eiffel>MUTEX</eiffel>, if a token is available, take it and return <code> True </code>, otherwise return <code> False </code>.
<code> my_sem.try_wait</code>
<code>
my_sem.try_wait</code>
{{caution|Be sure that a semaphore does not wait for a token when it is disposed }}
@@ -119,38 +134,44 @@ This class allows to use condition variables in Eiffel. An instance of class <ei
* Declaration of the condition variable
<code> my_cond: CONDITION_VARIABLE</code>
<code>
my_cond: CONDITION_VARIABLE</code>
* Creation:
<code> create my_cond.make</code>
<code>
create my_cond.make</code>
* Wait for a signal (send by <eiffel>signal</eiffel>). You need to use a mutex.
<code>
my_mutex: MUTEX
my_mutex: MUTEX
create my_mutex.make
...
create my_mutex.make
</code>
<code>my_mutex </code> must be locked by the calling thread so as <eiffel>wait</eiffel> can be called. <eiffel>wait</eiffel> atomically unlocks <code> my_mutex </code> and waits for the condition variable <code> my_mutex </code> to receive a signal. As soon as it received a signal, ''<code>my_cond </code>'' locks ''<code>my_mutex </code>''
<code>my_mutex</code> must be locked by the calling thread so as <eiffel>wait</eiffel> can be called. <eiffel>wait</eiffel> atomically unlocks <code> my_mutex </code> and waits for the condition variable <code> my_mutex </code> to receive a signal. As soon as it received a signal, ''<code>my_cond </code>'' locks ''<code>my_mutex </code>''
<code>
my_mutex.lock
-- You must lock `my_mutex' before calling wait.
my_mutex.lock
-- You must lock `my_mutex' before calling wait.
my_cond.wait (my_mutex)
-- Here the critical code to execute when `my_cond' received a signal.
my_cond.wait (my_mutex)
-- Here the critical code to execute when `my_cond' received a signal.
my_mutex.unlock
-- Unlock the mutex at the end of the critical section.
my_mutex.unlock
-- Unlock the mutex at the end of the critical section.
</code>
* Send a signal one thread blocked on the condition variable `my_cond'.
<code> my_cond.signal</code>
<code>
my_cond.signal</code>
* Send a signal to all the threads blocked on the condition variable `my_cond'.
<code> my_cond.broadcast</code>
<code>
my_cond.broadcast</code>
{{caution|Be sure that a condition variable is unblocked when it is disposed. }}
@@ -167,11 +188,12 @@ class <eiffel>THREAD_ATTRIBUTES</eiffel>: defines the attributes of an Eiffel Th
* <eiffel>join_all</eiffel>: the calling thread waits for all other threads to finished (all its children).
* A parent thread can wait for the termination of a child process through the feature <eiffel>join</eiffel> of class <eiffel>THREAD_CONTROL</eiffel> (inherited by <eiffel>THREAD</eiffel>):
<code>
thr: MY_THREAD
...
thr.launch
...
thr.join
thr: MY_THREAD
...
thr.launch
...
thr.join
</code>

4
documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/duration.wiki
View File

@@ -117,7 +117,7 @@ Features <eiffel>set_day</eiffel>, <eiffel>set_month</eiffel>, and <eiffel>set_y
<eiffel>DATE_TIME_DURATION</eiffel> is client of <eiffel>DATE_DURATION</eiffel> and <eiffel>TIME_DURATION</eiffel>. Most of the common features described in <eiffel>DATE_DURATION</eiffel> are present in the class. The class deals with its attributes date and time in the same way as <eiffel>DATE_TIME</eiffel>.
There are, as in <eiffel>DATE_DURATION</eiffel>, definite and non-definite durations. It is the date part which gives the definite non-definite status. Features canonical and to_canonical are present in <eiffel>DATE_TIME_DURATION</eiffel>. They have to deal with the attributes time.
There are, as in <eiffel>DATE_DURATION</eiffel>, definite and non-definite durations. It is the date part which gives the definite non-definite status. Features <eiffel>canonical</eiffel> and <eiffel>to_canonical</eiffel> are present in <eiffel>DATE_TIME_DURATION</eiffel>. They have to deal with the attributes time.
====Creation====
@@ -133,7 +133,7 @@ There are still several ways to create an instance:
====Comparison====
The rules are the same than those for <eiffel>DATE_DURATION</eiffel>. Features <eiffel><</eiffel>, <eiffel>></eiffel>,<eiffel><=</eiffel>, and <eiffel>>=</eiffel> are available. If both instances are definite, numbers of days are compared. If one of them is non-definite, the result is False.
The rules are the same than those for <eiffel>DATE_DURATION</eiffel>. Features <eiffel><</eiffel>, <eiffel>></eiffel>, <eiffel><=</eiffel>, and <eiffel>>=</eiffel> are available. If both instances are definite, numbers of days are compared. If one of them is non-definite, the result is False.
====Element change====

30
documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/overview-eiffelnet-mechanisms.wiki
View File

@@ -22,20 +22,20 @@ In network-style client-server communication, the mechanism will be dissymmetric
A software system will exchange objects with another by sending them to a socket. Although if you stay at the predefined level you will not need to manipulate sockets explicitly, it is useful to understand this concept and know about the corresponding EiffelNet classes.
You may think of a socket as a communication port; by attaching sockets together you enable communication between the corresponding systems, for example a client and a server:
[[Image:fig-2]]
[[Image:fig-2]]
EiffelNet has been designed so that sockets look very much like files. You send objects to a socket in the same way that you write objects onto a file, and receive objects from a socket in the same way that you read objects from a file. This fundamental commonality is reflected in the inheritance hierarchy of the corresponding classes:
[[Image:fig-3]]
Note that the hierarchy as shown is not complete; in particular the full structure uses classes STREAM (of which the <code> STREAM_ </code> classes are heirs) and <code> DATAGRAM </code> for multiple inheritance ''. ''Only the classes below the dotted line are part of EiffelNet; the others are part of EiffelBase, the fundamental data structure and algorithm library of ISE Eiffel [2].
[[Image:fig-3]]
Note that the hierarchy as shown is not complete; in particular the full structure uses classes STREAM (of which the <code> STREAM_ </code> classes are heirs) and <code> DATAGRAM </code> for multiple inheritance ''. ''Only the classes below the dotted line are part of EiffelNet; the others are part of EiffelBase, the fundamental data structure and algorithm library of ISE Eiffel [ [[Bibliography|2]] ].
The most important property of this inheritance hierarchy is that it shows how sockets fit within the overall structure. Thanks to the common ancestor <code>IO_MEDIUM</code>, socket classes have most of their features in common with files.
In normal usage, the only socket classes that you will need are four classes appearing at the bottom of the above figure. They correspond to two separate distinctions: single-machine versus multi-machine, and reliable versus unreliable.
On the first distinction:
* If the communicating systems run on the same machine, you may use one of the <code> UNIX_ </code> classes.
* For systems that run on different machines, you must use one of the <code> NETWORK_ </code> classes. This will also work if the systems are on the same machine, but less efficiently since communication may go through the network.
* If the communicating systems run on the same machine, you may use one of the <code>UNIX_ </code> classes.
* For systems that run on different machines, you must use one of the <code>NETWORK_ </code> classes. This will also work if the systems are on the same machine, but less efficiently since communication may go through the network.
The use of the word <code> UNIX_ </code> does not mean that the machine must be running the Unix operating system; rather, it denotes a certain style of client-server communication, the Unix style. (This is comparable to the use of the name <code> UNIX_FILE </code> in EiffelBase, for a class describing files that behave in the Unix style even though they may be implemented on non-Unix machines.)
The use of the word <code>UNIX_ </code> does not mean that the machine must be running the Unix operating system; rather, it denotes a certain style of client-server communication, the Unix style. (This is comparable to the use of the name <code>UNIX_FILE</code> in EiffelBase, for a class describing files that behave in the Unix style even though they may be implemented on non-Unix machines.)
The second distinction reflects two modes of socket communication: stream communication and datagram communication. Both of these modes support two-way communication between systems, but with different properties:
* A stream socket, as provided by the <code>STREAM_</code> classes, provides sequenced communication without any loss or duplication of data. Stream communication is normally synchronous: the sending system waits until it has established a connection to the receiving system and transmitted the data.
@@ -43,11 +43,12 @@ The second distinction reflects two modes of socket communication: stream commun
===Sending and receiving simple values===
<code>IO_MEDIUM</code> has all the basic input and output facilities applying to objects of basic types, as also offered in FILE(see the specification of<code> FILE</code> in reference [2]). So you can use sockets to send and receive characters, integers, real numbers in simple or double precision and strings. For example, if the type of
`my_socket' is one of the socket classes shown on the preceding figures, any of the above calls will be valid:
<code>IO_MEDIUM</code> has all the basic input and output facilities applying to objects of basic types, as also offered in FILE(see the specification of<code> FILE</code> in reference [ [[Bibliography|2]] ]). So you can use sockets to send and receive characters, integers, real numbers in simple or double precision and strings. For example, if the type of
`my_socket' is one of the socket classes shown on the preceding figures, any of the following calls will be valid:
<code>
my_socket.putstring ("Some text") my_socket.readint; my_last_integer := my_socketllastint
my_socket.putstring ("Some text")
my_socket.readint
my_last_integer := my_socket.lastint
</code>
Since sockets are bidirectional, these instructions may all appear as part of the same class provided you make sure to guarantee proper synchronization between senders and receivers. You may also prefer to specialize certain sockets for sending and others for receiving.
@@ -58,7 +59,7 @@ In many cases, what you will want to send and receive is not just simple values
The basic mechanism enabling a system to send objects through EiffelNet is also the basic mechanism for storing objects into a file: class <code>STORABLE</code> from EiffelBase.
As documented in [2], <code>STORABLE</code> provides features to store and retrieve complete object structures. There are three storage procedures, called under the respective forms
As documented in [ [[Bibliography|2]] ], <code>STORABLE</code> provides features to store and retrieve complete object structures. There are three storage procedures, called under the respective forms
<code>
struct1.basic_store (iom1)
struct1.general_store (iom1)
@@ -67,7 +68,7 @@ As documented in [2], <code>STORABLE</code> provides features to store and retri
Assuming that the type of ''iom1 ''is <code>IO_MEDIUM</code> or a conforming type such as [[ref:libraries/base/reference/file_chart|FILE]] or one of the <code>_SOCKET</code> classes, and that the type of ''struct1'' conforms to <code>STORABLE</code> ''.''Note that reference [2] in its original version does not include ''independent_store'', and requires ''iom'' to be of type FILE rather than the more general <code>IO_MEDIUM</code>. The current version of EiffelBase, however, supports the more general properties described here.
All three storage procedures have the effect of sending to ''iom1 ''(whether a file, a socket or some other IO-medium) a copy of the entire object structure starting at ''struc1''. Together with the retrieval routines seen below, they apply the principle of reference completeness stated in [1] and [2]:
All three storage procedures have the effect of sending to ''iom1 ''(whether a file, a socket or some other IO-medium) a copy of the entire object structure starting at ''struc1''. Together with the retrieval routines seen below, they apply the principle of reference completeness stated in [ [[Bibliography|1]] ] and [ [[Bibliography|2]] ]:
{| border="1"
|-
| Whenever a routine of class <code>STORABLE</code> stores an object into an external file, it stores with it the dependents of that object.
@@ -84,7 +85,8 @@ The three storage procedures differ in their degree of generality:
The penalty for using more general representations is that the data representation (as stored into the file or sent to the socket) will have to include more information. So ''basic_store ''uses the most compact representation, and ''independent_store'' the most verbose.
The scheme for accessing an object structure produced by one of these three procedures is the following, used in a descendant of class <code>STORABLE</code>:
<code> struct2 ?= retrieved (iom2)</code>
<code>
struct2 ?= retrieved (iom2)</code>
Here ''iom2'' must be of a type conforming to <code>IO_MEDIUM</code>. The assignment attempt ?= checks that the root object of the structure produced by the corresponding call to one of the ''_store'' procedures is of a type that conforms to the type of ''struct2''; if not, the assignment will assign to ''struct2'' a void reference.
@@ -99,7 +101,7 @@ Their main use is for a system that relies on datagram communication. As noted a
===Associating commands with events===
EiffelNet supports a highly asynchronous (and hence efficient) mode of operation by offering mechanisms through which you can specify that a certain action must be executed whenever a certain medium becomes available for reading, writing or handling of special cases (out of bounds). This facility is provided by a set of related classes:
* The actions are represented by class <code>POLL_COMMAND</code>, an heir of the EiffelBase class <code> COMMAND </code> with, in particular, the procedure ''execute''.
* The actions are represented by class <code>POLL_COMMAND</code>, an heir of the EiffelBase class <code>COMMAND</code> with, in particular, the procedure ''execute''.
* Using <code>MEDIUM_POLLER</code>, you can specify that a certain command (an instance of <code>POLL_COMMAND</code>) must be executed whenever a certain medium becomes available for the appropriate operation (read, write, handling of out-of-bounds cases).
* Using <code>POLL_MASK</code>, you can set a mask to select the sockets or files on which your instance of <code>MEDIUM_POLLER</code> is working.

2
documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/what-eiffelnet.wiki
View File

@@ -26,7 +26,7 @@ Familiarity with the basic concepts of client-server computing will also be help
===Organization of this manual===
[[Clients and servers|Section 2]] discusses the notion of client and server. [[An overview of EiffelNet Mechanisms|Section 3]] presents an overview of EiffelNet's facilities. [[The predefined level|Section 4]] describes the predefined level: a set of high-level classes that provide a complete framework, covering the most common uses and limiting the developer's work to the strict minimum. Sections [[Introduction to the examples|5]] to [[A more complex example|10]] describe the facilities in detail through a set of increasingly ambitious examples (whose texts may all be found in the directory '''$ISE_EIFFEL/examples/net''' of the Eiffel distribution). [[Clients and servers|Section 11]] is a short bibliography.
[[Clients and servers]] discusses the notion of client and server. [[An overview of EiffelNet Mechanisms]] presents an overview of EiffelNet's facilities. [[The predefined level]] describes the predefined level: a set of high-level classes that provide a complete framework, covering the most common uses and limiting the developer's work to the strict minimum. The sections titled [[Introduction to the examples]] through [[A more complex example]] describe the facilities in detail through a set of increasingly ambitious examples (whose texts may all be found in the directory '''$ISE_EIFFEL/examples/net''' of the Eiffel distribution). The final section is a short [[Bibliography]].

68
documentation/current/solutions/other-languages/cecil/cecil-interface-overview.wiki
View File

@@ -19,12 +19,12 @@ Generally, you should use these types when implementing external C functions bou
{{sample|Calling C external `foo' from Eiffel, which takes a pointer and an eiffel object of type OBJECT as arguments and returns an INTEGER. }}
<div>
<code>
c_foo (ptr: POINTER; obj: OBJECT): INTEGER is
external
"C | %"your_file.h%""
alias
"foo"
end
c_foo (ptr: POINTER; obj: OBJECT): INTEGER
external
"C | %"your_file.h%""
alias
"foo"
end
</code>
@@ -46,12 +46,12 @@ int foo (void *arg1, char c, FILE *file)
</code>
</div><div>To match the signature, you must declare it in Eiffel as:
<code>
c_foo (arg1: POINTER; c: CHARACTER; file: POINTER): INTEGER is
external
"C (void *, char, FILE *) : int | %""your_file.h%""
alias
"foo"
end
c_foo (arg1: POINTER; c: CHARACTER; file: POINTER): INTEGER
external
"C (void *, char, FILE *) : int | %""your_file.h%""
alias
"foo"
end
</code>
</div>
Not doing this would generally produce warnings during the C compilation, and it could crash with some C compilers.
@@ -91,12 +91,12 @@ Use ''eif_access'' to pass an Eiffel object to an Eiffel routine or to return th
'''For example, in the following external:'''
<code>
c_foo (ptr: POINTER; obj: OBJECT): INTEGER is
external
"C | %""your_file.h%""
alias
"foo"
end
c_foo (ptr: POINTER; obj: OBJECT): INTEGER
external
"C | %""your_file.h%""
alias
"foo"
end
</code>
@@ -191,18 +191,18 @@ Called within a C external, the function ''eif_adopt'' creates a user protection
In Eiffel:
<div>
<code>
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
c_foo (ptr: POINTER; obj: OBJECT): INTEGER
external
"C | %"your_file.h%""
alias
"foo"
end
c_display_and_release_obj
external
"C | %"your_file.h%""
alias
"display_and_release_obj"
end
</code>
</div>
@@ -403,10 +403,10 @@ See also <eiffel>eif_access</eiffel>.
In Eiffel:
<code>
foo : STRING is
external
"C | %"a file.h%""
end
foo : STRING
external
"C | %"a file.h%""
end
</code>
In C:

152
documentation/current/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals-0.wiki
View File

@@ -108,19 +108,19 @@ For example, a C++ function
should have the Eiffel counterpart
<code>
cpp_add (obj: POINTER; new_int: INTEGER) is
-- Encapsulation of member function add.
external
"C++ [IntArray %"intarray.h%"] (IntArray *, int)"
end
cpp_add (obj: POINTER; new_int: INTEGER)
-- Encapsulation of member function add.
external
"C++ [IntArray %"intarray.h%"] (IntArray *, int)"
end
</code>
This scheme, however, is often inconvenient because it forces the Eiffel side to work on objects in a non-object-oriented way. (The object-oriented way treats the current object, within a class, as implicit.) A better approach, used by Legacy++, is to make a feature such as cpp_add secret, and to export a feature whose signature corresponds to that of the original C++ function, with no extra object argument; that feature will use a secret attribute object_ptr to access the object. In the example this will give the feature
<code>
add (new_int: INTEGER) is
-- Encapsulation of member function add.
do
cpp_add (object_ptr, new_int)
end
add (new_int: INTEGER)
-- Encapsulation of member function add.
do
cpp_add (object_ptr, new_int)
end
</code>
where ''object_ptr'' is a secret attribute of type <eiffel>POINTER</eiffel>, initialized by the creation procedures of the class. To the Eiffel developer, <eiffel>add</eiffel> looks like a normal object-oriented feature, which takes only the expected argument. Further examples appear below. This technique only works of course when the C++ object is implicit in the context of the Eiffel class.
@@ -198,101 +198,101 @@ class IntArray {
Here is the result of applying Legacy++ to that class, which will serve as an illustration of both the C++ interface mechanisms and Legacy++:
<code>
indexing
description: "Eiffel encapsulation of C++ class IntArray";
date: "$Date: 2006-10-12 03:18:50 +0200 (Thu, 12 Oct 2006) $";
revision: "$Revision: 64319 $"
description: "Eiffel encapsulation of C++ class IntArray";
date: "$Date: 2006-10-12 03:18:50 +0200 (Thu, 12 Oct 2006) $";
revision: "$Revision: 64319 $"
class
INTARRAY
INTARRAY
inherit
MEMORY
redefine
dispose
end
MEMORY
redefine
dispose
end
create
make
make
feature -- Initialization
make (size: INTEGER) is
-- Create Eiffel and C++ objects.
do
object_ptr := cpp_new (size)
end
make (size: INTEGER)
-- Create Eiffel and C++ objects.
do
object_ptr := cpp_new (size)
end
feature-- Removal
dispose is
-- Delete C++ object.
do
cpp_delete (object_ptr)
end
dispose
-- Delete C++ object.
do
cpp_delete (object_ptr)
end
feature
output is
-- Call C++ counterpart.
do
cpp_output (object_ptr)
end
output
-- Call C++ counterpart.
do
cpp_output (object_ptr)
end
add (new_int: INTEGER) is
-- Call C++ counterpart.
do
cpp_add (object_ptr, new_int)
end
add (new_int: INTEGER)
-- Call C++ counterpart.
do
cpp_add (object_ptr, new_int)
end
feature {INTARRAY}
underscore_integers: POINTER is
-- Value of corresponding C++ data member.
do
Result := underscore_integers (object_ptr)
end
underscore_integers: POINTER
-- Value of corresponding C++ data member.
do
Result := underscore_integers (object_ptr)
end
feature {NONE} -- Externals
cpp_new (size: INTEGER): POINTER is
-- Call single constructor of C++ class.
external
"C++ [new IntArray %"INTARRAY.H%"] (EIF_INTEGER)"
end
cpp_new (size: INTEGER): POINTER
-- Call single constructor of C++ class.
external
"C++ [new IntArray %"INTARRAY.H%"] (EIF_INTEGER)"
end
cpp_delete (cpp_obj: POINTER) is
-- Call C++ destructor on C++ object.
external
"C++ [delete IntArray %"INTARRAY.H%"] ()"
end
cpp_delete (cpp_obj: POINTER)
-- Call C++ destructor on C++ object.
external
"C++ [delete IntArray %"INTARRAY.H%"] ()"
end
cpp_output (cpp_obj: POINTER) is
-- Call C++ member function.
external
"C++ [IntArray %"INTARRAY.H%"] ()"
alias
"output"
end
cpp_output (cpp_obj: POINTER)
-- Call C++ member function.
external
"C++ [IntArray %"INTARRAY.H%"] ()"
alias
"output"
end
cpp_add (cpp_obj: POINTER; new_int: INTEGER) is
-- Call C++ member function.
external
"C++ [IntArray %"INTARRAY.H%"] (EIF_INTEGER)"
alias
"add"
end
cpp_add (cpp_obj: POINTER; new_int: INTEGER)
-- Call C++ member function.
external
"C++ [IntArray %"INTARRAY.H%"] (EIF_INTEGER)"
alias
"add"
end
cpp_underscore_integers (cpp_obj: POINTER): POINTER is
-- Value of C++ data member
external
"C++ [data_member IntArray %"INTARRAY.H%"]: EIF_POINTER"
alias
"_integers"
end
cpp_underscore_integers (cpp_obj: POINTER): POINTER
-- Value of C++ data member
external
"C++ [data_member IntArray %"INTARRAY.H%"]: EIF_POINTER"
alias
"_integers"
end
feature {NONE} -- Implementation
object_ptr: POINTER
object_ptr: POINTER
end -- class INTARRAY
</code>

28
documentation/current/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals.wiki
View File

@@ -30,7 +30,7 @@ extern size_t one_param_return(FILE *f);</code>
Here is the corresponding Eiffel code:
<code>
c_no_param is
c_no_param
-- Encapsulation of a C routine with no parameter.
external
"C | %"my_header.h%""
@@ -38,7 +38,7 @@ Here is the corresponding Eiffel code:
"no_param"
end
c_one_param (i: INTEGER) is
c_one_param (i: INTEGER)
-- Encapsulation of a C routine with one parameter.
external
"C (int) | %"my_header.h%""
@@ -46,7 +46,7 @@ Here is the corresponding Eiffel code:
"one_param"
end
c_no_param_return: INTEGER is
c_no_param_return: INTEGER
-- Encapsulation of a C routine with no parameter
-- returning an INTEGER
external
@@ -55,7 +55,7 @@ Here is the corresponding Eiffel code:
"no_param_return"
end
c_one_param_return (p: POINTER): INTEGER is
c_one_param_return (p: POINTER): INTEGER
-- Encapsulation of a C routine with one parameter
-- returning an INTEGER
external
@@ -82,7 +82,7 @@ Then, the corresponding Eiffel code will look like:
<code>
menu_id: INTEGER is
menu_id: INTEGER
-- `ID_MENU' C encapsulation.
external
"C [macro %"my_header.h%"] : EIF_INTEGER"
@@ -90,7 +90,7 @@ Then, the corresponding Eiffel code will look like:
"ID_MENU"
end
menu_id_character: CHARACTER is
menu_id_character: CHARACTER
-- `ID_MENU_CHARACTER' C encapsulation.
external
"C [macro %"my_header.h%"] : EIF_CHARACTER"
@@ -98,7 +98,7 @@ Then, the corresponding Eiffel code will look like:
"ID_MENU_CHARACTER"
end
i_th (p: POINTER; i: INTEGER): INTEGER is
i_th (p: POINTER; i: INTEGER): INTEGER
-- Access the `i'-th element of `p', array of C EIF_INTEGER.
external
"C [macro %"my_header.h%"] (EIF_INTEGER *, EIF_INTEGER): EIF_INTEGER"
@@ -125,7 +125,7 @@ typdef struct point {
Then, the corresponding Eiffel code will look like:
<code>
x (p: POINTER): INTEGER is
x (p: POINTER): INTEGER
-- Access field x of struct pointed by `p'.
external
"C [struct %"my_header.h%"] (Point): EIF_INTEGER"
@@ -133,7 +133,7 @@ Then, the corresponding Eiffel code will look like:
"x"
end
y (p: POINTER): INTEGER is
y (p: POINTER): INTEGER
-- Access field y of struct pointed by `p'.
external
"C [struct %"my_header.h%"] (Point): EIF_INTEGER"
@@ -141,7 +141,7 @@ Then, the corresponding Eiffel code will look like:
"y"
end
set_x (p: POINTER; v: INTEGER) is
set_x (p: POINTER; v: INTEGER)
-- Set field x of struct pointed by `p'.
external
"C [struct %"my_header.h%"] (Point, int)"
@@ -149,7 +149,7 @@ Then, the corresponding Eiffel code will look like:
"x"
end
set_y (p: POINTER: v: INTEGER) is
set_y (p: POINTER: v: INTEGER)
-- Set field y of struct pointed by `p' with `v'.
external
"C [struct %"my_header.h%"] (Point, int)"
@@ -171,13 +171,13 @@ Therefore if you want to call an external routine defined in a DLL supposed to b
<code>
my_cdecl_routine (a: INTEGER): POINTER is
my_cdecl_routine (a: INTEGER): POINTER
-- Encapsulation of a dll function with the `_cdecl' call mechanism.
external
"C [dll32 %"my_dll.dll%"] (int): EIF_POINTER"
end
my_stdcall_routine (a: INTEGER): POINTER is
my_stdcall_routine (a: INTEGER): POINTER
-- Encapsulation of a dll function with the `_stdcall' call mechanism.
external
"C [dllwin32 %"my_dll.dll%"] (int): EIF_POINTER"
@@ -207,7 +207,7 @@ In WEL, the encapsulation is written as:
<code>
cwin_send_message (hwnd: POINTER; msg, wparam, param: INTEGER) is
cwin_send_message (hwnd: POINTER; msg, wparam, param: INTEGER)
-- SDK SendMessage (without the result)
external
"C [macro %"wel.h%"] (HWND, UINT, WPARAM, LPARAM)"

85
documentation/current/solutions/other-languages/eiffel2java/eiffel2java-sample.wiki
View File

@@ -43,58 +43,59 @@ Value of `my_integer' after call to `my_method' is 2
===Code description===
<code>(Eiffel Code)
class
EIFFEL_TO_JAVA
inherit
SHARED_JNI_ENVIRONMENT
class
EIFFEL_TO_JAVA
inherit
SHARED_JNI_ENVIRONMENT
create
make
make
feature -- Creation
feature -- Creation
make is
local
class_test: JAVA_CLASS
instance_of_class_test: JAVA_OBJECT
fid: POINTER
value: INTEGER
j_args: JAVA_ARGS
do
--| Creation of the Java object
class_test := jni.find_class ("test")
create instance_of_class_test.create_instance (class_test, "()V", Void)
make
local
class_test: JAVA_CLASS
instance_of_class_test: JAVA_OBJECT
fid: POINTER
value: INTEGER
j_args: JAVA_ARGS
do
--| Creation of the Java object
class_test := jni.find_class ("test")
create instance_of_class_test.create_instance (class_test, "()V", Void)
--| Access to a public attribute
fid := instance_of_class_test.field_id ("my_integer", "I")
--| Access to a public attribute
fid := instance_of_class_test.field_id ("my_integer", "I")
-- 'fid' contains the id of the field 'my_integer'
-- 'value' contains the value of the field referenced
-- by 'fid'
-- 'fid' contains the id of the field 'my_integer'
-- 'value' contains the value of the field referenced
-- by 'fid'
value := instance_of_class_test.integer_attribute (fid)
value := instance_of_class_test.integer_attribute (fid)
--| Access to a static attribute using directly the JAVA_CLASS
fid := class_test.field_id ("my_static_integer", "I")
value := class_test.integer_attribute (fid) ...
--| Access to a static attribute using the attribute 'jclass'
fid := instance_of_class_test.jclass.field_id ("my_static_integer", "I")
value := instance_of_class_test.jclass.integer_attribute (fid)
--| Access to the method 'my_method'
-- Get the id of 'my_method'
fid := instance_of_class_test.method_id ("my_method", "(ILjava/lang/String;)V")
--| Access to a static attribute using directly the JAVA_CLASS
fid := class_test.field_id ("my_static_integer", "I")
value := class_test.integer_attribute (fid)
-- Create the set of arguments for 'my_method'
create j_args.make(2)
j_args.push_int (2)
j_args.push_string("String test")
-- Create the set of arguments for 'my_method'
-- Call to the void method referenced by 'fid'
instance_of_class_test.void_method (fid, j_args)
end -- make
--| Access to a static attribute using the attribute 'jclass'
fid := instance_of_class_test.jclass.field_id ("my_static_integer", "I")
value := instance_of_class_test.jclass.integer_attribute (fid)
--| Access to the method 'my_method'
-- Get the id of 'my_method'
fid := instance_of_class_test.method_id ("my_method", "(ILjava/lang/String;)V")
-- Create the set of arguments for 'my_method'
create j_args.make(2)
j_args.push_int (2)
j_args.push_string("String test")
-- Create the set of arguments for 'my_method'
-- Call to the void method referenced by 'fid'
instance_of_class_test.void_method (fid, j_args)
end -- make
end -- class EIFFEL_TO_JAVA</code>

17
documentation/current/solutions/other-languages/eiffel2java/eiffel2java-tutorial.wiki
View File

@@ -10,14 +10,15 @@ The Java interface allows you to call Java routines or attributes from your Eiff
===Requirements===
* JDK 1.1.8 or newer should be correctly set up (download it at [http://java.sun.com/javase/downloads/index.jsp http://java.sun.com/javase/downloads/index.jsp] )
* The environment variable CLASSPATH should defined (check with the JDK documentation on how to do so) and that it contains the Java classes you want to access.
* The environment variables should be setup correctly. See $ISE_EIFFEL\library\Eiffel2Java\README.txt for information how to do this..
* The environment variables should be setup correctly. See $ISE_EIFFEL\library\Eiffel2Java\README.txt for information how to do this.
===Borland users===
On Windows, the JDK includes a set of C libraries which have been compiled for the Microsoft C compiler. Before being able to use the JDK from Eiffel you need to perform the following operation:
# In $JDK_HOME\lib, rename javai.lib into javai.lib.microsoft
# From the DOS command prompt and in the directory $JDK_HOME\lib, launch the following command <br/>
<code>%ISE_EIFFEL%\bcc55\bin\implib javai.lib..\bin\javai.dll</code>
<code lang=text>
%ISE_EIFFEL%\bcc55\bin\implib javai.lib..\bin\javai.dll</code>
===Limitations===
@@ -143,17 +144,21 @@ When you want to call a Java method or access a field, you need to specify its s
|}
The signature for a Java class has the following form:
<code>L fully-qualified-class;</code>
<code lang=text>
L fully-qualified-class;</code>
For example, class String:
<code>Ljava/lang/String;</code>
<code lang=text>
Ljava/lang/String;</code>
The signature for a method has the following form:
<code>(arguments-types) returned-types</code>
<code lang=text>
(arguments-types) returned-types</code>
For example, the signature of a method that takes as arguments an integer and a string and return void is:
<code>(ILjava/lang/String;)V</code>
<code lang=text>
(ILjava/lang/String;)V</code>