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=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!ncar!gatech!hubcap!billwolf From: billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) Newsgroups: comp.lang.ada Subject: Re: Garbage Collection Message-ID: <4041@hubcap.UUCP> Date: 8 Jan 89 18:40:00 GMT References: <4222@enea.se> Sender: news@hubcap.UUCP Reply-To: billwolf@hubcap.clemson.edu List-Id: >From article <4222@enea.se>, by sommar@enea.se (Erland Sommarskog): > [Still discussing Erland's example regarding automatic destruction > of a local environment upon block exit. Erland now states precisely > that he is instantiating a tree which stores objects of type pointer; > in other words, we are dealing with a tree of pointers. The example > continues with a situation in which a pointer is being inserted into > the tree.] > > Procedure Put_something_in_tree(Tree : in out Tree_type; > Anything : Any_type) is > Reference : Some_access_type; > Begin > Reference := new Some_type; > Do_something(Reference.all, Anything); > Tree_handler.Insert(Tree, Reference); > End; > > Question: What happens with Reference.all when Put_something_in_tree > is exited? I read your proposal as that it should be deallocated, > which would be disastrous. Or is this a misunderstanding from my > side? If it is not: is this code erroneous with your scheme? It is a misunderstanding from your side. I stated in the preceding version of the example (or maybe the first version, or both) that since Reference is a simple pointer, destruction of Reference consists only of eliminating the space occupied by the pointer, and does not imply destruction of what Reference points to. Now let's consider: procedure EXAMPLE (INPUT : SOME_ADT) is TEMP : SOME_ADT; -- now TEMP happens to be *implemented* -- as a pointer to TEMP's descriptor, -- which in turn contains other pointers -- to TEMP's value. But since TEMP is -- limited private, our user doesn't know that. ACCESS_AN_INTEGER : access INTEGER; -- a local object begin ASSIGN (TEMP, SOME_OPERATION (SOME_ADT)); ACCESS_AN_INTEGER := new INTEGER := SIZE_OF (TEMP); -- notice the allocation... DO_SOMETHING_WITH (TEMP, SOME_ADT, ACCESS_AN_INTEGER); DO_SOMETHING_ELSE_WITH (TEMP, ACCESS_AN_INTEGER); -- -- notice failure to deallocate ACCESS_AN_INTEGER.all... -- end EXAMPLE; -- OK, now at this point we are done with TEMP. It is a -- local variable, and therefore its DESTROY procedure -- will be automatically invoked. We are also done with -- ACCESS_AN_INTEGER, so ACCESS_AN_INTEGER will also be -- destroyed. But since ACCESS_AN_INTEGER is only a -- pointer, this leaves the integer value to become -- garbage! We conclude that our user requires -- more programming experience, so that he/she -- might more completely comprehend the characteristics -- of the programming tool known as the pointer. > Side note: you said that the tree package should take a Destroy > procedure. For what benefit? You can't automatically call it when > your Destroy_tree is called. The caller might refer to the stored > objects in some other place. You're forgetting that the caller completely controls what happens inside that caller-supplied DESTROY procedure! If the caller so desires, the DESTROY procedure can consist of a null statement; then only the routine destruction of the space occupied by the pointer will occur, as an effect of the call to UNCHECKED_DEALLOCATION which destroys the space occupied by the record describing a given node. Secure in the knowledge that the caller is responsible for prescribing the destruction procedure, Destroy_Tree will in fact call Destroy automatically on each and every instance of a stored object. Bill Wolfe wtwolfe@hubcap.clemson.edu