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,74b55538385b7366 X-Google-Attributes: gid103376,public From: Florian Weimer Subject: Re: Which is right here - GNAT or OA ? Date: 1999/06/05 Message-ID: #1/1 X-Deja-AN: 485997727 References: <928083159.436.79@news.remarQ.com> <928174549.336.98@news.remarQ.com> <7iuqkc$ln6$1@nnrp1.deja.com> <928529202.956.79@news.remarQ.com> Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@cygnus.stuttgart.netsurf.de X-Trace: deneb.cygnus.stuttgart.netsurf.de 928584822 12268 192.168.0.1 (5 Jun 1999 12:13:42 GMT) Organization: Penguin on board Mime-Version: 1.0 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/21.1 (20 Minutes to Nikko) NNTP-Posting-Date: 5 Jun 1999 12:13:42 GMT Newsgroups: comp.lang.ada Date: 1999-06-05T12:13:42+00:00 List-Id: "Vladimir Olensky" writes: > When Free(X) is invoked then RTS could do something like this (in reality > it may be much more complex): [Heuristics based on the internal access value representation snipped] > Such solution have very little overhead and it is not very difficult to > be implemented. Maybe that's true, but it does not work. Consider the following situation: type A is record X: Integer; end record; type B is record Y: aliased A; end record; type B_Access is access B; Z: B_Access := new B; Your heuristics fails for Z.Y'Access, because this access value references an object which has been created indirectly by an allocator. On all architectures I can imagine, the internal machine representation of Z.Y'Access will look very like that of an access to an object which has been directly created by an allocator, although the value of Z.Y'Access certainly isn't a valid argument for Ada.Unchecked_Deallocation. Of course, it is possible to ensure that Ada.Unchecked_Deallocation raises an exception if it encounters an access-to-variable, but this requires some non-trivial changes. A few possible implementations come to my mind: colored pointers, fat pointers, hidden record fields (your suggestion; problematic with scalar types and possibly with records with representation clauses, also some space concerns), colored tags for tagged records, support from a garbage collector. They all don't seem very appealing to me and probably won't handle all kinds of Ada objects consistently (except perhaps garbage collection ;). One very reasonable way to solve this kind of problem was already pointed out: Use an abstract data type which hides allocation and deallocation details in the implementation. This way, you never have to call Ada.Unchecked_Deallocation directly (outside the implementation, of course), and you can't accidently deallocate an object which isn't located in a storage pool.