comp.lang.ada
 help / color / mirror / Atom feed
From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Free'ing dynamic abstract tagged types..
Date: Thu, 21 Sep 2006 17:12:09 -0500
Date: 2006-09-21T17:12:09-05:00	[thread overview]
Message-ID: <uNidneizepC7k47YnZ2dnUVZ_sGdnZ2d@megapath.net> (raw)
In-Reply-To: 1158872883.994303.80430@b28g2000cwb.googlegroups.com

"ldb" <ldb_nospam@hotmail.com> wrote in message
news:1158872883.994303.80430@b28g2000cwb.googlegroups.com...
> Ok, so I have this abstract tagged type called Person (for the sake of
> discussion), and I have an Access_Person (which is access all
> people'class).
>
> I have some derived types, like Man and Child, with their own added
> fields. And I have defined Access_Man, Access_Child, as normal accesses
> to these types.
>
> I want to free an Access_Person that was dynamically allocated.
> ap : Access_Person;
> begin
> ap := Access_Person(new Man);
> free(ap);
> ...
>
> I can't figure out how to write the free routine, since unchecked
> deallocation wants a pointer (presumably access_man), but all I have is
> a class-wide pointer, and I can't figure out how, or if, I can convert
> it. Does that make sense?

No. ;-)

You just free the access and let the compiler take care of it. That is, just
instantiate Unchecked_Deallocation appropriately:

    procedure Person_Free is new Ada.Unchecked_Deallocation (Person'Class,
Access_Person);

and then call it.

> Using free(ap.all), I can make an abstract function that will dispatch
> and free any nested allocations, but I can't seem to get it to free the
> record, itself.

Right, you have to do that on the pointer. You could write something like:

          procedure Free (P :  Access_Person) is
          begin
                 Free (P.all); -- Free the contents
                 Person_Free (P); -- Free the object itself.
          end Free;

but if the derived types need internal clean-up, it's better to make the
whole tree controlled and let the compiler do all of the internal clean-up:
that makes it much harder to forget.

Since you can't add Controlled to an inheritance tree after the fact, I
think that *all* tagged type trees should be derived from Controlled or
Limited_Controlled. (Otherwise, you're saying that the extensions don't need
any clean-up, which is likely to be constraining.)

                                  Randy.





  reply	other threads:[~2006-09-21 22:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-21 21:08 Free'ing dynamic abstract tagged types ldb
2006-09-21 22:12 ` Randy Brukardt [this message]
2006-09-22  7:41   ` Alex R. Mosteo
2006-09-26  0:08     ` Randy Brukardt
2006-09-21 22:12 ` Robert A Duff
2006-09-22  7:21 ` Dmitry A. Kazakov
2006-09-22 21:59 ` Jeffrey R. Carter
replies disabled

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