[comp.lang.eiffel] Class STRING bug

shelley@atc.sps.mot.com (Norman K. Shelley) (07/25/90)

class NEW_STRING
inherit
	STRING;	-- notice that Create is not renamed
feature
... 
end; -- NEW_STRING

Object of class NEW_STRING does not use STRING's Create (or allocate) to
allocate some string storage space. When equal, putstring, etc. are applied to
this object, the system will crash with a segmentation error!

One way to solve this is to add the following to STRING's invariant:

not area.Void;

This will protect future heirs from this problem! Also, one could then take out
the check for "not area.Void" within the routine "count" as it is not
necessary.

If one allows "area.Void" then one must put many checks for "not area.Void" in
MANY more spots than the one it is currently in!!

Norman Shelley
Motorola - ATC
2200 W. Broadway AZ09/M350
Mesa, AZ 85202
...!uunet!motsps!atc!shelley
shelley@atc.sps.mot.com
(602) 962-2473

belle@skipper.dfrf.nasa.gov (Steve Belle) (07/25/90)

In article <2339@dover.sps.mot.com>, shelley@atc.sps.mot.com (Norman K.
Shelley) writes:
|> class NEW_STRING
|> inherit
|> 	STRING;	-- notice that Create is not renamed
|> feature
|> ... 
|> end; -- NEW_STRING
|> 
|> Object of class NEW_STRING does not use STRING's Create (or allocate) to
|> allocate some string storage space. When equal, putstring, etc. are
applied to
|> this object, the system will crash with a segmentation error!

On page 56 of "Eiffel: The Language", it states that "Create is never
inherited, as
each class usually needs to have its own method for create instances,
independent
from its parents'."   In Eiffel 2.2, the above is not a bug in STRING, but an 
incorrect implementation of the inheritence mechanism.  There is a margin note 
indicating a change in this mechanism in version 3.

Steve Belle
belle@skipper.dfrf.nasa.gov