Previous Table of Contents Next


The predefined feature Void denotes a void reference. You can make x void through the assignment x := Void and test whether it is void through if x = Void then .... The type of Void is NONE, the least interesting class (section 9.5.4).

The features introduced in this section—copy, clone, is_equal, equal, and Void—are not language constructs but features defined in the highest-level class GENERAL (section 9.5.4) and hence available to all classes. Void is of type NONE. Using the redefinition mechanisms mentioned in the discussion of inheritance, a class can redefine copy and is_equal to describe specific notions of copy and equality. (The assertions ensure that the two remain compatible: After x.copy (y), the property x.is_equal (y) must always be true.) Redefining copy automatically causes clone to follow, and redefining is_equal automatically causes equal to follow. Void too should not be redefined. To avoid any mistake, these features are declared as “frozen”—not redefinable. To guarantee the original, non-redefined semantics, you can use the frozen variants standard_copy, standard_clone, standard_equal, and so on.

9.6.11. Deep Operations and Persistence

Feature clone only duplicates one object. If some of the fields of that object are references to other objects, the references themselves are copied, not those other objects.

It is useful, in some cases, to duplicate not just one object but an entire object structure. The expression deep_clone (y) achieves this goal: Assuming non-void y, it produces a duplicate not just of the object attached to y but of the entire object structure starting at that object. The mechanism of course respects all the possible details of that structure, such as cyclic reference chains. As earlier features, deep_clone comes from class GENERAL.

A related mechanism provides a powerful persistence facility. A call of the form

   x.store (Some_file_or_network_connection)

(using the conventions of ISE Eiffel) stores a copy of the entire object structure starting at x, under a suitable representation. Like deep_clone, procedure store follows all references to the end and maintains the properties of the structure. The function retrieved can then be used—in the same system, or another—to recreate the structure from the stored version.

As the name suggests, Some_file_or_network_connection can be an external medium of various possible kinds, not just a file but possibly a database or network. ISE’s EiffelNet client/server library indeed uses the store-retrieved mechanism to exchange object structures over a network, between compatible or different machine architectures—for example, a Windows client and a UNIX server.

9.6.12. Memory Management

Reference reattachments x := y of the form illustrated by Figure 9.9 can cause objects to become unreachable. This is the case for the object identified as OBJ2 on that figure (the object to which x was attached before the assignment) if no other reference was attached to it.

In all but toy systems, it is essential to reclaim the memory that has been allocated for such objects; otherwise, memory usage could grow forever, as a result of creation instructions !! x ... and calls to clone and the like, leading to thrashing and eventually to catastrophic termination.

Unlike some other approaches, the Eiffel method suggests that the task of detecting and reclaiming such unused object space should be handled by an automatic mechanism (part of the Eiffel runtime environment), not manually by developers (through calls to procedures such as Pascal’s dispose and C/C++’s free). The arguments for this view are

  Convenience—Handling memory reclamation manually can add enormous complication to the software, especially when—as is often the case in object-oriented development—the system manipulates complex runtime data structures with many links and cycles.
  Reliability—Memory management errors, such as the incorrect reclamation of an object that is still referenced by a distant part of the structure, are a notorious source of particularly dangerous and hard-to-correct bugs.

Eiffel environments have developed sophisticated garbage collectors that efficiently handle the automatic reclamation process, while causing no visible degradation of a system’s performance and response time.

Reliance on automatic garbage collection is a key part of the Eiffel method’s contribution to both ease of development and software reliability.


Previous Table of Contents Next