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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c3a7c1845ec5caf9 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Equality operator overloading in ADA 83 Date: 1997/04/27 Message-ID: #1/1 X-Deja-AN: 237699758 References: <01bc4e9b$ac0e7fa0$72041dc2@lightning> <335E0B1F.12C9@elca-matrix.ch> <335F5971.6375@elca-matrix.ch> <33671d9c.5046069@news.airmail.net> <3360ABA6.7D55@elca-matrix.ch> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-04-27T00:00:00+00:00 List-Id: Mats says <", ">=", "<=" are defined (but I realize it's too late now, this should have been done in Ada 83).>> This would be a terrible idea, since it would build in serious inefficiencies. A typical way of implementing comparisons for a complex type is to have a single comparison routine that indicates the compare status (LT, EQ, GT) and then have the operators be a simple wrapper around this routine. Your automatically constructed cases would introduce serious inefficiencies, typically doubling the time of some complex comparisons. FOr instance, you define "<=" as "<" or "=", but look at the following from the GNAT ureal package (arbitrary precision reals): ----------- -- UR_Le -- ----------- function UR_Le (Left, Right : Ureal) return Boolean is begin return not (Right < Left); end UR_Le; (and the "<=" operator renames UR_Le) Your approach would make this important operation take twice as long ... Yes, I suppose I could get around it with caching, but that is messy to do in a task safe manner. I don't like this idea at all, and if it was ever suggested for Ada 83 (I can't remember it having come up, but it must be something the design team considered), then it was correctly rejected in my view.