Re: Garbage Collection

[billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,)]

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