Free'ing dynamic abstract tagged types..

Free'ing dynamic abstract tagged types..

[ldb]

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?

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.

Re: Free'ing dynamic abstract tagged types..

[Randy Brukardt]

"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.

Re: Free'ing dynamic abstract tagged types..

[Robert A Duff]

"ldb" <ldb_nospam@hotmail.com> writes:

> 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?

You should use the same access type for allocation and deallocation.
That is, if the result type of your "new" is Some_Access_Type,
you should instantiate Unchecked_Deallocation with Some_Access_Type.

- Bob

Re: Free'ing dynamic abstract tagged types..

[Dmitry A. Kazakov]

On 21 Sep 2006 14:08:04 -0700, ldb wrote:

> 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.

That usually were a bad idea, because it creates a parallel types
hierarchy:

Person <-- Man
Specific_Access_Person <-- Specific_Access_Man

Maintaining both is an unnecessary burden.

Note that you can allocate Man having Access_Person as the target. Usual
pattern is:

   Man_Ptr : Access_Person := new Man;
      -- OK, we want to access some fields of Man after having
      -- created it, so:
   declare
      Object : Man'Class renames Man'Class (Man_Ptr.all);
   begin
      -- Do with Object what you have to with Man. Object
      -- is not new, it is a Man'Class view of the thing pointed
      -- by Man_Ptr.
      ...
   end;

> I want to free an Access_Person that was dynamically allocated.
> ap : Access_Person;
> begin
> ap := Access_Person(new Man);
> free(ap);
> ...

Others have answered this.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Free'ing dynamic abstract tagged types..

[Alex R. Mosteo]

Randy Brukardt wrote:

(snip) 
> 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.)

This is something I've wondered some times with the introduction of
interfaces in Ada05: Could not have been defined in Ada.Finalization a
corresponding interface? This way objects not rooted at Controlled could
later easily add finalization.

Re: Free'ing dynamic abstract tagged types..

[Jeffrey R. Carter]

ldb wrote:
> 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).

The 1st question is: Why do you have an access type?

-- 
Jeff Carter
"All citizens will be required to change their underwear
every half hour. Underwear will be worn on the outside,
so we can check."
Bananas
29

Re: Free'ing dynamic abstract tagged types..

[Randy Brukardt]

"Alex R. Mosteo" <devnull@mailinator.com> wrote in message
news:4nhic5Fajj8vU1@individual.net...
> Randy Brukardt wrote:
>
> (snip)
> > 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.)
>
> This is something I've wondered some times with the introduction of
> interfaces in Ada05: Could not have been defined in Ada.Finalization a
> corresponding interface? This way objects not rooted at Controlled could
> later easily add finalization.

It could have been done that way, but it would be very incompatible (so it
couldn't be done now). Two reasons: (1) [weaker] implementations use hidden
data to implement controlled types; if we're going to make implementers do
that for this one case, we should be doing it generally [that is, full
multiple inheritance] (and we were not willing to pay that implementation
price, because it would make all tagged types less efficient); (2)
[stronger] since we cannot allow hidden interfaces, any private types
implemented with controlled types would become illegal. Yuck.

Note that this question is commonly enough asked that it actually is
described in the AARM: 7.6(9.d). See
http://www.adaic.com/standards/05aarm/html/AA-7-6.html.

                                          Randy.