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.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,924aad49bcf9e4e7
X-Google-Attributes: gid103376,public
From: "Norman H. Cohen" <ncohen@watson.ibm.com>
Subject: Re: Cumbersome Polymorphism
Date: 1997/01/27
Message-ID: <32ECF2A3.6371@watson.ibm.com>#1/1
X-Deja-AN: 212591797
references: <32E7ABE8.3BF3@eurocontrol.fr>
content-type: text/plain; charset=us-ascii
organization: IBM Thomas J. Watson Research Center
mime-version: 1.0
reply-to: ncohen@watson.ibm.com
newsgroups: comp.lang.ada
x-mailer: Mozilla 3.0 (Win95; I)
Date: 1997-01-27T00:00:00+00:00
List-Id: <comp.lang.ada>


Richard Irvine wrote:

> ----------
> Solution 2
> ----------
> 
> package Types is
> 
>   type Abstract_Type is abstract tagged null record;
> 
>   procedure Do_Something_To(A_Descendent : Abstract_Type);
> 
>   type Access_Abstract_Type_Class is access Abstract_Type'Class;
> 
>   type Descendent1 is new Abstract_Type with null record;
> 
>   type Descendent2 is new Abstract_Type with null record;
> 
> end;
> 
> package body A_Package is
> 
>   Access_The_Stored_Descendent : Access_Abstract_Type_Class;
> 
>   procedure Store(A_Descendent : Abstract_Type'Class)
>   is
>   begin
>      Access_The_Stored_Descendent :=
>         new Abstract_Type'Class'(A_Descendent);
>   end;
> 
>   procedure Do_Something_To_The_Stored_Descendent
>   is
>   begin
>     Do_Something_To(Access_The_Stored_Descendent.all);
>   end;
> 
> end;
> 
> This is a possible solution to the problem.
...
> However, it seems that in order to make a very simple use of
> polymorphism, I have been obliged to introduce access types.

Yes, this is generally the case in Ada 95.

> And now by bringing in access types I have imported the problems
> that go with them.

You are using an access type in a very restricted and disciplined way. 
I'm not sure what you mean by "the problems that go with them", but the
fact that undisciplined use of access types may cause problems is
irrelevant.  Your solution does not involve any such problems.

> The above package does not free the storage which is allocated
> in the Store operation.
> In this case, I could simply introduce an explicit deallocation
> in the Store operation, before allocating new storage.

That is precisely the right approach:

   procedure Store(A_Descendent : Abstract_Type'Class) is
      procedure Free is
         new Ada.Unchecked_Deallocation
           (Abstract_Type'Class, Access_Abstract_Type_Class);
   begin
      Free (Access_The_Stored_Descendent);
         -- A no-op if Access_The_Stored_Descedent is
         --    already null.
      Access_The_Stored_Descendent :=
         new Abstract_Type'Class'(A_Descendent);
   end;
 

> However, as is well known, the problem with requiring the user
> of a type to perform explicit deallocation is that he may forget
> to do so somewhere in the code, resulting in a memory leak.

I don't understand the problem.  The need for the deallocation operation
is encapsulated in the package.  The writer of the package ensures that
there is never more than one object allocated.  The user of the type
never has to know about it.  Indeed, the declaration of your access type
ought to be moved out of the package declaration and into the package
body.
 
> Of course, Ada provides a mechanism for automating deallocation,
> using controlled types, so a better solution would make use of this:

The use of controlled types is not warranted in this situation.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen