From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4c86cf2332cbe682 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-01-22 10:05:43 PST Newsgroups: comp.lang.ada Path: nntp.gmd.de!newsserver.jvnc.net!howland.reston.ans.net!pipex!uunet!noc.near.net!inmet!henning!stt From: stt@henning.camb.inmet.com (Tucker Taft) Subject: Re: Ada.strings.bounded problems? Message-ID: Sender: news@inmet.camb.inmet.com Organization: Intermetrics, Inc. References: <1995Jan18.164836.2222@nbivax.nbi.dk> Date: Sun, 22 Jan 1995 18:05:43 GMT Date: 1995-01-22T18:05:43+00:00 List-Id: In article <1995Jan18.164836.2222@nbivax.nbi.dk>, Jacob Sparre Andersen wrote: >Mats Weber (Mats.Weber@matrix.ch) wrote: >| In article <3fduto$ta7@watnews1.watson.ibm.com>, >| ncohen@watson.ibm.com wrote: >| > function "=" (Left, Right: Bounded_String) return Boolean is ... >| >| This helps some, but still has severe problems. For instance if I write >| >| type Pair is >| record >| First, >| Second : Bounded_String; >| end record; >| >| then "=" is broken for Pair. This situation is very bad because overriding >| "=" on Bounded_String gives the programmer the feeling that the problem is >| solved, but it reappears whenever a Bounded_String is used as a component >| of a composite type. >|__________ > >It this really true? I would say that if it is, it a serious problem with >Ada. This is true for untagged types, for upward compatibility reasons. In general in Ada 83, predefined operators "reemerge" under certain contexts (e.g. in a generic on the formal type, or in a composite operation such as "<" on an array). The reason for the reemergence can be traced both to semantic and implementation difficulties associated with disallowing reemergence. For example, when a predefined operator of an untagged type is overridden, the overriding need not necessarily conform exactly to the original operators profile, nor satisfy the original operator's semantic properties (as might be expected by a generic unit). For tagged types, once "=" is overridden, the predefined operator will never "reemerge," neither in generics nor in a composite operation such as "=" on an array, record, or type extension. Exact "subtype" conformance is required when overriding "=" on a tagged type (or when overriding any inherited primitive operation on a tagged type). This distinction should be remembered when deciding whether to make a given abstract type tagged or not. In general, if the programmer wants complete control over a type, the type will need to be tagged (and perhaps also "controlled"). As pointed out by others, providing a default initialization for the "tail" of an array is an alternative way to avoid any problems associated with "partially" initialized nested arrays. >Regards, > Jacob Sparre Andersen S. Tucker Taft stt@inmet.com Ada 9X Mapping/Revision Team Intermetrics, Inc. Cambridge, MA 02138