Author:halw

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

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]]

View File

@@ -26,13 +26,13 @@ class
feature -- Access
object_per_thread: OBJECT is
object_per_thread: OBJECT
-- Once per thread.
once
create Result.make
end
object_per_process: OBJECT is
object_per_process: OBJECT
-- New 'object' (once per process)
-- that could be shared between threads
-- without reinitializing it.

View File

@@ -18,11 +18,12 @@ Your thread is represented by a class which inherits from <eiffel>THREAD</eiffel
feature
execute is
execute
-- define the deferred feature from THREAD.
do
...
end
...
end -- class MY_THREAD
@@ -37,6 +38,8 @@ Creating a thread is like creating an Eiffel object:
-- MY_THREAD inherits from THREAD and defines
-- the deferred procedure `execute'
...
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,15 +134,19 @@ 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
...
create my_mutex.make
</code>
@@ -147,10 +166,12 @@ This class allows to use condition variables in Eiffel. An instance of class <ei
* 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. }}
@@ -169,6 +190,7 @@ class <eiffel>THREAD_ATTRIBUTES</eiffel>: defines the attributes of an Eiffel Th
<code>
thr: MY_THREAD
...
thr.launch
...
thr.join

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====

View File

@@ -25,7 +25,7 @@ You may think of a socket as a communication port; by attaching sockets together
[[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].
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.
@@ -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.

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]].

View File

@@ -19,7 +19,7 @@ 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
c_foo (ptr: POINTER; obj: OBJECT): INTEGER
external
"C | %"your_file.h%""
alias
@@ -46,7 +46,7 @@ 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
c_foo (arg1: POINTER; c: CHARACTER; file: POINTER): INTEGER
external
"C (void *, char, FILE *) : int | %""your_file.h%""
alias
@@ -91,7 +91,7 @@ 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
c_foo (ptr: POINTER; obj: OBJECT): INTEGER
external
"C | %""your_file.h%""
alias
@@ -191,13 +191,13 @@ 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
c_foo (ptr: POINTER; obj: OBJECT): INTEGER
external
"C | %"your_file.h%""
alias
"foo"
end
c_display_and_release_obj is
c_display_and_release_obj
external
"C | %"your_file.h%""
alias
@@ -403,7 +403,7 @@ See also <eiffel>eif_access</eiffel>.
In Eiffel:
<code>
foo : STRING is
foo : STRING
external
"C | %"a file.h%""
end

View File

@@ -108,7 +108,7 @@ For example, a C++ function
should have the Eiffel counterpart
<code>
cpp_add (obj: POINTER; new_int: INTEGER) is
cpp_add (obj: POINTER; new_int: INTEGER)
-- Encapsulation of member function add.
external
"C++ [IntArray %"intarray.h%"] (IntArray *, int)"
@@ -116,7 +116,7 @@ should have the Eiffel counterpart
</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
add (new_int: INTEGER)
-- Encapsulation of member function add.
do
cpp_add (object_ptr, new_int)
@@ -216,7 +216,7 @@ create
feature -- Initialization
make (size: INTEGER) is
make (size: INTEGER)
-- Create Eiffel and C++ objects.
do
object_ptr := cpp_new (size)
@@ -224,7 +224,7 @@ feature -- Initialization
feature-- Removal
dispose is
dispose
-- Delete C++ object.
do
cpp_delete (object_ptr)
@@ -232,13 +232,13 @@ feature-- Removal
feature
output is
output
-- Call C++ counterpart.
do
cpp_output (object_ptr)
end
add (new_int: INTEGER) is
add (new_int: INTEGER)
-- Call C++ counterpart.
do
cpp_add (object_ptr, new_int)
@@ -246,7 +246,7 @@ feature
feature {INTARRAY}
underscore_integers: POINTER is
underscore_integers: POINTER
-- Value of corresponding C++ data member.
do
Result := underscore_integers (object_ptr)
@@ -254,19 +254,19 @@ feature {INTARRAY}
feature {NONE} -- Externals
cpp_new (size: INTEGER): POINTER is
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
cpp_delete (cpp_obj: POINTER)
-- Call C++ destructor on C++ object.
external
"C++ [delete IntArray %"INTARRAY.H%"] ()"
end
cpp_output (cpp_obj: POINTER) is
cpp_output (cpp_obj: POINTER)
-- Call C++ member function.
external
"C++ [IntArray %"INTARRAY.H%"] ()"
@@ -274,7 +274,7 @@ feature {NONE} -- Externals
"output"
end
cpp_add (cpp_obj: POINTER; new_int: INTEGER) is
cpp_add (cpp_obj: POINTER; new_int: INTEGER)
-- Call C++ member function.
external
"C++ [IntArray %"INTARRAY.H%"] (EIF_INTEGER)"
@@ -282,7 +282,7 @@ feature {NONE} -- Externals
"add"
end
cpp_underscore_integers (cpp_obj: POINTER): POINTER is
cpp_underscore_integers (cpp_obj: POINTER): POINTER
-- Value of C++ data member
external
"C++ [data_member IntArray %"INTARRAY.H%"]: EIF_POINTER"

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)"

View File

@@ -53,7 +53,7 @@ create
feature -- Creation
make is
make
local
class_test: JAVA_CLASS
instance_of_class_test: JAVA_OBJECT
@@ -76,7 +76,8 @@ feature -- Creation
--| 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) ...
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")

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>