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: jsa@alexandria (Jon S Anthony) Subject: Re: Equality operator overloading in ADA 83 Date: 1997/04/25 Message-ID: #1/1 X-Deja-AN: 237343742 Distribution: world References: <01bc4e9b$ac0e7fa0$72041dc2@lightning> <33692089.5794807@news.airmail.net> Organization: PSI Public Usenet Link Newsgroups: comp.lang.ada Date: 1997-04-25T00:00:00+00:00 List-Id: In article bobduff@world.std.com (Robert A Duff) writes: > No, the heap is the right solution to true varying-length strings. > Unfortunately, Ada 83 doesn't give you the tools needed to avoid storage > leaks without breaking the abstraction. The tool needed is either > garbage collection, or finalization and user-defined assignment. I strongly agree with this. Of course (as you all know by now) I would go further and say that GC is really the only good solution here. Even if it were only for strings. Finalization and user defined assignment are typically going to be rather more expensive. > "More inefficient" than what? Than C's nul-terminated strings? Perhaps > true, at least in many cases. But Ada strings *are* more inefficient > than they *could* be. In particular, there's no way to fix the lower > bound to 1, so the generated code has to carry around 8 bytes of dope, > where 4 would suffice. And do a subtract to determine the length. Or > carry 12 bytes, to avoid the subtract. Don't tell me to use a > discriminated record, because then I lose all kinds of nice notations > (like indexing, slicing, and string literals). Sad, but true... /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com