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-18 17:36:14 PST Newsgroups: comp.lang.ada Path: nntp.gmd.de!Germany.EU.net!howland.reston.ans.net!pipex!uunet!telesoft!kst From: kst@alsys.com (Keith Thompson) Subject: Re: Ada.strings.bounded problems? Message-ID: Originator: kst@pulsar Sender: news@thomsoft.com (USENET News Admin @flash) Organization: Thomson Software Products, San Diego, CA, USA References: <3f3rl7$kts@watnews1.watson.ibm.com> <3fduto$ta7@watnews1.watson.ibm.com> Date: Thu, 19 Jan 1995 01:36:14 GMT Date: 1995-01-19T01:36:14+00:00 List-Id: In Mats.Weber@matrix.ch (Mats Weber) writes: > In article <3fduto$ta7@watnews1.watson.ibm.com>, ncohen@watson.ibm.com wrote: > > Ada 95 allows predefined equality to be overridden, even for nonlimited > > types, so the declaration of a type Bounded_String with a discriminant > > specifying the maximum length should be accompanied by the declaration > > for the following function: > > > > 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. Interesting. This is a potential problem that didn't occur (as seriously) in Ada 83. Since Ada 83 only allowed "=" to be overloaded for limited types, and a type with a limited component is also limited, a type with a subcomponent that has a user-defined "=" operator generally wouldn't have its own "=" operator unless the user explicitly defined one (unless you used the generic trick). In Ada 95, it's very easy to have a case like the above where the user-defined "=" operator for a subcomponent is bypassed. Section II-6.3 of the Rationale, which discusses overloading of "=" and "/=", doesn't mention this problem. Quite possibly it was simply overlooked. It's obviously too late to fix this in the language by requiring predefined "=" to invoke user-defined "=" for subcomponents. I suggest that Ada 95 compilers should issue a warning for a type whose predefined "=" operator bypasses a user-defined "=" operator for a subcomponent. Determining exactly when to issue such a warning may be difficult ("=" can be declared to return a type other than Standard.Boolean, the left and right operands can be different types, "=" and "/=" can be overloaded separately in some circumstances, the declaration for "=" needn't be in the same scope as the operand type(s), etc.), but catching the most common cases shouldn't be difficult. -- Keith Thompson (The_Other_Keith) kst@thomsoft.com (kst@alsys.com still works) TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718 When you're a nail, every problem looks like a hammer.