Void-safe changes to Eiffel libraries

Overview

During the adoption of void-safety, the software libraries provided by Eiffel Software have been converted to be void-safe. The bulk of the changes made to these libraries will have little or no adverse effect on your existing software as you go through the process of void-safe conversion. However, there are a few changes to the library that we consider "breaking" changes, that is, important changes that might cause problems in existing systems that use certain library classes.

Note: Many of these changes were in effect in the experimental mode of versions 6.4 and 6.5. With the release of version 6.6, the experimental mode of previous versions became the default mode and, consequently may have caused these changes to become more apparent to some users. A compatibility mode is available to ease transition. The compatibility mode is accessible using the -compat command line option or through the EiffelStudio choices provided through the Microsoft Windows Start button.

Important changes to library classes

Class ARRAY

New preconditions

Some additional preconditions are in force in ARRAY in void-safe mode.

In void-unsafe mode, the behavior is equivalent to that of previous versions.

Feature make_from_special

The signature of this routine has changed.

Current signature: make_from_special (a: SPECIAL [G])

Previous signature: make_from_special (a: SPECIAL [G]; min_index, max_index: INTEGER)

Using the current version will create an array with a range from 1 to the number of elements in the argument a.

Feature auto_resize

This implementation (private) feature has been removed.

Class ARRAYED_LIST

Relationship to ARRAY

Previously ARRAYED_LIST conformed to ARRAY. This is no longer the case. The feature {ARRAYED_LIST}.to_array can be used to produce an instance of ARRAY from an instance of ARRAYED_LIST.

Features count and area

Previously these two queries, count and area, were attributes. They are now functions.

Class HASH_TABLE

The internal implementation has changed in ways that cause the order of traversal to differ from previous versions.

Classes SPECIAL and TO_SPECIAL

Feature {SPECIAL}.make

This void-unsafe feature has been removed.

In its place, the creation procedures {SPECIAL}.make_filled and {SPECIAL}.make_empty can be used.

{SPECIAL}.make_filled is available in both default and compatible modes. Use this creation procedure if you want code that is compatible with both modes.

{SPECIAL}.make_empty is available in default mode only.

Feature {TO_SPECIAL}.make_area

In order to reflect the above change to class SPECIAL, the make_area feature of TO_SPECIAL has been removed in favor of {TO_SPECIAL}.make_filled_area and {TO_SPECIAL}.make_empty_area.

The availability of {TO_SPECIAL}.make_filled_area and {TO_SPECIAL}.make_empty_area corresponds to that noted above for the creation features of SPECIAL:

{TO_SPECIAL}.make_filled_area is available in both default and compatible modes. Use make_filled_area for code that needs to compile in both modes.

{TO_SPECIAL}.make_empty_area is available only in default mode.

Relationship of feature {SPECIAL}.count to {SPECIAL}.capacity

In previous versions, for a particular instance of SPECIAL the queries count and capacity yielded the same value.

This is no longer always true. If an instance of SPECIAL is created with, for example, make_empty (10), although the capacity will be 10, the count will be zero.

However creating a SPECIAL using make_filled will produce an instance in which count and capacity are equal upon creation. So the behavior is similar to that of previous versions. Also, make_filled is available in both default and compatible modes.

If your code depends upon count and capacity having the same value, then you can use make_filled for creation. And then if you need resizing, use the "_with_default" versions of the "resized" features, specifically resized_area_with_default and aliased_resized_area_with_default.