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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3b637950a34ec2d6 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-05-09 13:29:02 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Discriminated record question Date: Thu, 9 May 2002 15:29:17 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <5ee5b646.0205081852.4e2c20dc@posting.google.com> X-Newsreader: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 X-Complaints-To: newsabuse@supernews.com Xref: archiver1.google.com comp.lang.ada:23801 Date: 2002-05-09T15:29:17-05:00 List-Id: Robert Dewar wrote in message <5ee5b646.0205081852.4e2c20dc@posting.google.com>... >"Randy Brukardt" wrote in message news:... >> Janus/Ada does that (in both Ada 83 and Ada 95). I used >> to think that that was the only reasonable model, but it >> is clear that the implicit heap use is a bad thing in >> certain environments. > >Alsys used to do this as well in Ada 83. Did anyone get >it quite right? Alsys did not allow such beasts to be >nested in full generality, since this leads to complex >non-contiguous representations. > >At least one other Ada 83 compiler trying this (Janus?) >had storage leaks, and was so nice as to warn you that >declaring the type would cause a storage leak. > >(it is non-trivial to avoid storage leaks, if you allow >these implicit heap pointers to nest). Right, Janus/Ada 83 had significant storage leaks in a few cases. The primary problem was that the code at runtime did not know which heap the implicit data was allocated from, so it couldn't know the correct way to deallocate it. This is solved (I think) in Ada 95 with storage pools. Since every object has an associated storage pool (usually its implicit) anyway, and the thunks have to pass them around anyway, the deallocations can be done safely. (Tuck as recently convinced me that the storage pool implementation is wrong for nested scopes, but that's unrelated to the deallocation problem.) We still give the non-contiguous type warning, though, because it says that taking 'Address on the object may not be a good idea, etc. >It is definitely a bad idea for a compiler. If you want pointers and dynamic allocation, >write it that way. The job of a compiler is to make programming as easy as possible for a given language. Putting arbitrary limits on a language feature doesn't meet that goal IMHO. >As far as I am concerned, for a language at the level of Ada, it is a >bad idea in *all* cases to do implicit heap allocations for a type declaration of this kind. You may be right, but then I would argue that the language is incorrectly designed. Because it suggests that you can create an object without determining the size until runtime, but that is not really true. (Not that I have a better idea for the language.) The current situation requires an arbitrary maximum size to be determined ahead of time, and incorrectly choosing that size breaks the portability of your code. Randy.