From bba0936e07b7e9afc65dd53ffcb921d213e978b7 Mon Sep 17 00:00:00 2001 From: halw Date: Mon, 1 Dec 2008 22:45:08 +0000 Subject: [PATCH] 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 --- .../index.wiki | 2 +- .../once-features-multithreaded-mode.wiki | 30 ++-- .../thread-library-overview.wiki | 116 +++++++------ .../eiffeltime-tutorial/duration.wiki | 4 +- .../overview-eiffelnet-mechanisms.wiki | 30 ++-- .../eiffelnet-tutorial/what-eiffelnet.wiki | 2 +- .../cecil/cecil-interface-overview.wiki | 68 ++++---- .../c-externals-0.wiki | 152 +++++++++--------- .../c-externals.wiki | 28 ++-- .../eiffel2java/eiffel2java-sample.wiki | 85 +++++----- .../eiffel2java/eiffel2java-tutorial.wiki | 17 +- 11 files changed, 282 insertions(+), 252 deletions(-) diff --git a/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/index.wiki b/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/index.wiki index 9486e937..6d32a8ae 100644 --- a/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/index.wiki +++ b/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/index.wiki @@ -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]] diff --git a/documentation/current/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/once-features-multithreaded-mode.wiki b/documentation/current/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/once-features-multithreaded-mode.wiki index 45f73e54..60b2eea4 100644 --- a/documentation/current/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/once-features-multithreaded-mode.wiki +++ b/documentation/current/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/once-features-multithreaded-mode.wiki @@ -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: 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 diff --git a/documentation/current/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/thread-library-overview.wiki b/documentation/current/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/thread-library-overview.wiki index 37301c1c..6b5e0ae7 100644 --- a/documentation/current/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/thread-library-overview.wiki +++ b/documentation/current/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/thread-library-overview.wiki @@ -9,23 +9,24 @@ The class of the thread object you want to create should inherit the THR Your thread is represented by a class which inherits from THREAD (deferred class).
- 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 @@ -33,11 +34,13 @@ Creating a thread is like creating an Eiffel object: - 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 @@ -45,7 +48,8 @@ Creating a thread is like creating an Eiffel object: To run the thread, use the feature launch from THREAD. }} - my_thread.launch + + my_thread.launch On the Eiffel side, the procedure execute will be launched. This procedures deferred in class THREAD, you have to define it in MY_THREAD. @@ -66,22 +70,28 @@ The implementation of the class MUTEX is mapped on the C standa * Declaration of the mutex: - my_mutex: MUTEX + + my_mutex: MUTEX * Creation of mutex: - create my_mutex.make + + create my_mutex.make * Locking the mutex: - my_mutex.lock + + my_mutex.lock * Unlocking the mutex: - my_mutex.unlock + + my_mutex.unlock * try_lock: if it is not locked yet, lock the mutex and return True, otherwise it returns False. - my_mutex.try_lock + + my_mutex.try_lock * Is my mutex initialized? - my_mutex.is_set + + my_mutex.is_set {{note|on Windows: The MUTEX 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 MUTEX, the features of this class are mapped on the C thre * Declaration of the semaphore : - my_sem: SEMAPHORE + + my_sem: SEMAPHORE Creation of semaphore: initialize semaphore with nb_tokens, it requires nb_tokens > = 0 - create my_sem.make (nb_tokens) + + create my_sem.make (nb_tokens) * Wait for a token: - my_sem.wait + + my_sem.wait * Give back a token: - my_sem.post + + my_sem.post * try_wait, similar to try_lock from MUTEX, if a token is available, take it and return True , otherwise return False . - my_sem.try_wait + + my_sem.try_wait {{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 my_cond: CONDITION_VARIABLE + + my_cond: CONDITION_VARIABLE * Creation: - create my_cond.make + + create my_cond.make * Wait for a signal (send by signal). You need to use a mutex. - my_mutex: MUTEX + my_mutex: MUTEX - create my_mutex.make + ... + + create my_mutex.make -my_mutex must be locked by the calling thread so as wait can be called. wait atomically unlocks my_mutex and waits for the condition variable my_mutex to receive a signal. As soon as it received a signal, ''my_cond '' locks ''my_mutex '' +my_mutex must be locked by the calling thread so as wait can be called. wait atomically unlocks my_mutex and waits for the condition variable my_mutex to receive a signal. As soon as it received a signal, ''my_cond '' locks ''my_mutex '' - 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. * Send a signal one thread blocked on the condition variable `my_cond'. - my_cond.signal + + my_cond.signal * Send a signal to all the threads blocked on the condition variable `my_cond'. - my_cond.broadcast + + my_cond.broadcast {{caution|Be sure that a condition variable is unblocked when it is disposed. }} @@ -167,11 +188,12 @@ class THREAD_ATTRIBUTES: defines the attributes of an Eiffel Th * join_all: 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 join of class THREAD_CONTROL (inherited by THREAD): - thr: MY_THREAD - ... - thr.launch - ... - thr.join + thr: MY_THREAD + ... + + thr.launch + ... + thr.join diff --git a/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/duration.wiki b/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/duration.wiki index 4193c2f5..1bde7b35 100644 --- a/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/duration.wiki +++ b/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/duration.wiki @@ -117,7 +117,7 @@ Features set_day, set_month, and set_y DATE_TIME_DURATION is client of DATE_DURATION and TIME_DURATION. Most of the common features described in DATE_DURATION are present in the class. The class deals with its attributes date and time in the same way as DATE_TIME. -There are, as in DATE_DURATION, 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 DATE_TIME_DURATION. They have to deal with the attributes time. +There are, as in DATE_DURATION, 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 DATE_TIME_DURATION. 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 DATE_DURATION. Features <, >,<=, and >= 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 DATE_DURATION. Features <, >, <=, and >= 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==== diff --git a/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/overview-eiffelnet-mechanisms.wiki b/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/overview-eiffelnet-mechanisms.wiki index e388676e..ec158763 100644 --- a/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/overview-eiffelnet-mechanisms.wiki +++ b/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/overview-eiffelnet-mechanisms.wiki @@ -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 STREAM_ classes are heirs) and DATAGRAM 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 STREAM_ classes are heirs) and DATAGRAM 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 IO_MEDIUM, 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 UNIX_ classes. -* For systems that run on different machines, you must use one of the NETWORK_ 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 UNIX_ classes. +* For systems that run on different machines, you must use one of the NETWORK_ 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 UNIX_ 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 UNIX_FILE 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 UNIX_ 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 UNIX_FILE 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 STREAM_ 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=== -IO_MEDIUM has all the basic input and output facilities applying to objects of basic types, as also offered in FILE(see the specification of FILE 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: +IO_MEDIUM has all the basic input and output facilities applying to objects of basic types, as also offered in FILE(see the specification of FILE 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: - 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 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 STORABLE from EiffelBase. -As documented in [2], STORABLE provides features to store and retrieve complete object structures. There are three storage procedures, called under the respective forms +As documented in [ [[Bibliography|2]] ], STORABLE provides features to store and retrieve complete object structures. There are three storage procedures, called under the respective forms struct1.basic_store (iom1) struct1.general_store (iom1) @@ -67,7 +68,7 @@ As documented in [2], STORABLE provides features to store and retri Assuming that the type of ''iom1 ''is IO_MEDIUM or a conforming type such as [[ref:libraries/base/reference/file_chart|FILE]] or one of the _SOCKET classes, and that the type of ''struct1'' conforms to STORABLE ''.''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 IO_MEDIUM. 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 STORABLE 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 STORABLE: - struct2 ?= retrieved (iom2) + + struct2 ?= retrieved (iom2) Here ''iom2'' must be of a type conforming to IO_MEDIUM. 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 POLL_COMMAND, an heir of the EiffelBase class COMMAND with, in particular, the procedure ''execute''. +* The actions are represented by class POLL_COMMAND, an heir of the EiffelBase class COMMAND with, in particular, the procedure ''execute''. * Using MEDIUM_POLLER, you can specify that a certain command (an instance of POLL_COMMAND) must be executed whenever a certain medium becomes available for the appropriate operation (read, write, handling of out-of-bounds cases). * Using POLL_MASK, you can set a mask to select the sockets or files on which your instance of MEDIUM_POLLER is working. diff --git a/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/what-eiffelnet.wiki b/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/what-eiffelnet.wiki index f5822578..93807c98 100644 --- a/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/what-eiffelnet.wiki +++ b/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/what-eiffelnet.wiki @@ -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]]. diff --git a/documentation/current/solutions/other-languages/cecil/cecil-interface-overview.wiki b/documentation/current/solutions/other-languages/cecil/cecil-interface-overview.wiki index b136b326..75afdfd6 100644 --- a/documentation/current/solutions/other-languages/cecil/cecil-interface-overview.wiki +++ b/documentation/current/solutions/other-languages/cecil/cecil-interface-overview.wiki @@ -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. }}
- 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 @@ -46,12 +46,12 @@ int foo (void *arg1, char c, FILE *file)
To match the signature, you must declare it in Eiffel as: - 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
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:''' - 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 @@ -191,18 +191,18 @@ Called within a C external, the function ''eif_adopt'' creates a user protection 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 + 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
@@ -403,10 +403,10 @@ See also eif_access. In Eiffel: - foo : STRING is - external - "C | %"a file.h%"" - end + foo : STRING + external + "C | %"a file.h%"" + end In C: diff --git a/documentation/current/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals-0.wiki b/documentation/current/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals-0.wiki index 0957e8e7..e59644ed 100644 --- a/documentation/current/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals-0.wiki +++ b/documentation/current/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals-0.wiki @@ -108,19 +108,19 @@ For example, a C++ function should have the Eiffel counterpart - 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 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 - 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 where ''object_ptr'' is a secret attribute of type POINTER, initialized by the creation procedures of the class. To the Eiffel developer, add 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++: 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 diff --git a/documentation/current/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals.wiki b/documentation/current/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals.wiki index a2a3177d..acca5656 100644 --- a/documentation/current/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals.wiki +++ b/documentation/current/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals.wiki @@ -30,7 +30,7 @@ extern size_t one_param_return(FILE *f); Here is the corresponding Eiffel 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: - 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: - 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 - 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: - 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)" diff --git a/documentation/current/solutions/other-languages/eiffel2java/eiffel2java-sample.wiki b/documentation/current/solutions/other-languages/eiffel2java/eiffel2java-sample.wiki index 077a719e..364e788e 100644 --- a/documentation/current/solutions/other-languages/eiffel2java/eiffel2java-sample.wiki +++ b/documentation/current/solutions/other-languages/eiffel2java/eiffel2java-sample.wiki @@ -43,58 +43,59 @@ Value of `my_integer' after call to `my_method' is 2 ===Code description=== (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 diff --git a/documentation/current/solutions/other-languages/eiffel2java/eiffel2java-tutorial.wiki b/documentation/current/solutions/other-languages/eiffel2java/eiffel2java-tutorial.wiki index 6f09c162..28f10dea 100644 --- a/documentation/current/solutions/other-languages/eiffel2java/eiffel2java-tutorial.wiki +++ b/documentation/current/solutions/other-languages/eiffel2java/eiffel2java-tutorial.wiki @@ -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
-%ISE_EIFFEL%\bcc55\bin\implib javai.lib..\bin\javai.dll + +%ISE_EIFFEL%\bcc55\bin\implib javai.lib..\bin\javai.dll ===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: -L fully-qualified-class; + +L fully-qualified-class; For example, class String: -Ljava/lang/String; + +Ljava/lang/String; The signature for a method has the following form: -(arguments-types) returned-types + +(arguments-types) returned-types For example, the signature of a method that takes as arguments an integer and a string and return void is: -(ILjava/lang/String;)V + +(ILjava/lang/String;)V