comp.lang.ada
 help / color / mirror / Atom feed
From: "Norman H. Cohen" <ncohen@watson.ibm.com>
Subject: Re: Cumbersome Polymorphism
Date: 1997/01/27
Date: 1997-01-27T00:00:00+00:00	[thread overview]
Message-ID: <32ECF2A3.6371@watson.ibm.com> (raw)
In-Reply-To: 32E7ABE8.3BF3@eurocontrol.fr


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




  reply	other threads:[~1997-01-27  0:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-01-23  0:00 Cumbersome Polymorphism Richard Irvine
1997-01-27  0:00 ` Norman H. Cohen [this message]
1997-01-28  0:00   ` Richard Irvine
1997-01-28  0:00   ` Jon S Anthony
1997-01-28  0:00   ` Dave Gibson
     [not found] ` <5c9put$48t@hetre.wanadoo.fr>
1997-01-25  0:00   ` James O'Connor
1997-01-25  0:00   ` Robert A Duff
1997-01-25  0:00     ` James O'Connor
1997-01-26  0:00       ` Robert Dewar
1997-01-26  0:00       ` Brian Rogoff
1997-01-27  0:00   ` Jon S Anthony
1997-01-29  0:00     ` Robert Dewar
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox