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,3dbb4bb0201c39eb X-Google-Attributes: gid103376,public From: eachus@spectre.mitre.org (Robert I. Eachus) Subject: Re: Destructor question Date: 1998/12/08 Message-ID: #1/1 X-Deja-AN: 420092112 References: <3665B85D.A2663591@nowhere.com> <3666BACC.99E6BB06@spam.innocon.com> <3666F7F1.9B107D38@nowhere.com> Organization: The Mitre Corp., Bedford, MA. Newsgroups: comp.lang.ada Date: 1998-12-08T00:00:00+00:00 List-Id: In article Matthew Heaney writes: > An alternative implementation uses a (private) subprogram that takes an > access parameter: > procedure Do_Deallocate (The_Object : access Object); > This of course dispatches on the tag of The_Object. It more-or-less > combines the two parameters of Bob's solution into one parameter. This is essentially a style issue, but for didactic purposes, I wanted to avoid the clash between access parameters and Unchecked_Deallocation. Matt's example deals with this correctly, but it is probably more difficult for someone learning Ada to understand. > I prefer to instantiate Unchecked_Deallocation using a specific > type, rather than a class-wide one. I understand, I think, what Matt meant to say here from context, but it is tough to put in correct words. "I prefer to instantiate Unchecked_Deallocation where neither the object type nor the designated type in the formal access parameter is classwide," may be more correct, but it is certainly much harder on the eyes. The difference between Matt's implementation and mine here is in the type designated by the access type, and I just chose to use the one in the original example. However, I strongly agree that you do not want to instantiate Unchecked_Deallocation with a classwide object type. Language lawyers can argue about when this is required to work by the RM but allowed just to not collect the storage (or just do a lot of otherwise unnecessary checking) and when it is allowed to erroneusly collect the wrong amount of storage, but you are much better off not putting the gun to the implementors head. (The problem is that if you instantiate using a classwide type, the compiler won't know when the sizes of the objects of a given subtype are static, and when thunks or some other dynamic method is necessary to determine the amount of space to free. So a "correct" implementation will potentially require creating thunks for all possible target subtypes. If you instantiate for a specific type, even if it is inside a dispatching operation, then the compiler can generate decent code for each instance. Of course, the implementation of the standard storage pool may include a size in each object, but that doesn't help with user defined pools.) -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is...