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-08 19:52:14 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: dewar@gnat.com (Robert Dewar) Newsgroups: comp.lang.ada Subject: Re: Discriminated record question Date: 8 May 2002 19:52:14 -0700 Organization: http://groups.google.com/ Message-ID: <5ee5b646.0205081852.4e2c20dc@posting.google.com> References: NNTP-Posting-Host: 205.232.38.14 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1020912734 1889 127.0.0.1 (9 May 2002 02:52:14 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 9 May 2002 02:52:14 GMT Xref: archiver1.google.com comp.lang.ada:23749 Date: 2002-05-09T02:52:14+00:00 List-Id: "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). It is definitely a bad idea for a compiler. If you want pointers and dynamic allocation, write it that way. 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.