non-library level finalization

non-library level finalization

[tmoran]

I have a generic package that would benefit from doing some cleanup when
an instantiation disappears.  It can't just declare a (private)
Finalization_Controlled object because that would require all
instantiations to be at library level.  Suggestions?

Re: non-library level finalization

[Martin Dowie]

tmoran@acm.org wrote:
> I have a generic package that would benefit from doing some cleanup
> when an instantiation disappears.  It can't just declare a (private)
> Finalization_Controlled object because that would require all
> instantiations to be at library level.  Suggestions?

Other than waiting for Ada2005...

...could you wrap it in some sort of Unbounded_String - isn't there
some sort of compiler 'magic' required to ensure that there is effectively
some sort of GC for this type? (RM A.4.5 "No storage associated with
an Unbounded_String object shall be lost upon assignment or scope exit.").

Not sure how you'd get this to work (I'm barely awake yet!) but just a
thought...

Cheers

-- Martin

Re: Ada2005 again, was: non-library level finalization

[Tapio Kelloniemi]

"Martin Dowie" <martin.dowie@baesystems.com> wrote:
>tmoran@acm.org wrote:
>> I have a generic package that would benefit from doing some cleanup
>> when an instantiation disappears.  It can't just declare a (private)
>> Finalization_Controlled object because that would require all
>> instantiations to be at library level.  Suggestions?
>
>Other than waiting for Ada2005...

What method does Ada2005 provide to handle this problem? And in general,
is there some sort of summary which lists changes in Ada2005 (with
references to corresponding AI's). I know where AI's are stored, but
there are quite many of them and looking through all of them to just look
up their summary line is quite a slow process.

I have read the AdaCore's ada2005 page, but it is not accurate enough
and lists only major changes.

-- 
Tapio

Re: Ada2005 again, was: non-library level finalization

[Martin Dowie]

Tapio Kelloniemi wrote:
> "Martin Dowie" <martin.dowie@baesystems.com> wrote:
>> tmoran@acm.org wrote:
>>> I have a generic package that would benefit from doing some cleanup
>>> when an instantiation disappears.  It can't just declare a (private)
>>> Finalization_Controlled object because that would require all
>>> instantiations to be at library level.  Suggestions?
>>
>> Other than waiting for Ada2005...
>
> What method does Ada2005 provide to handle this problem?

It will allow nested type hierarchies. This is needed to avoid the need to
instantiate each and every container type at library level.

See:
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00344.TXT


> And in
> general, is there some sort of summary which lists changes in Ada2005
> (with references to corresponding AI's). I know where AI's are
> stored, but there are quite many of them and looking through all of
> them to just look up their summary line is quite a slow process.
>
> I have read the AdaCore's ada2005 page, but it is not accurate enough
> and lists only major changes.

I believe John Barnes is producing something but I know of no timescale.

The AdaCore page is also (slightly) inaccurate - there isn't going to be a
standard "socket" package.

Cheers

-- Martin

Re: non-library level finalization

[Robert A Duff]

tmoran@acm.org writes:

> I have a generic package that would benefit from doing some cleanup when
> an instantiation disappears.  It can't just declare a (private)
> Finalization_Controlled object because that would require all
> instantiations to be at library level.  Suggestions?

If you can arrange to declare the controlled type outside the generic,
you can still declare the object inside the generic.  But if the cleanup
code needs to work with the generic formal parameters, that won't work.

Probably your best bet is to live with the library-level restriction.
You can still *use* instances from nested places.

- Bob

Re: non-library level finalization

[Randy Brukardt]

Get Ada 2005, in which that restriction is removed?? :-)

                 Randy.

<tmoran@acm.org> wrote in message news:eIKdnT-oNJ6gvqPfRVn-pA@comcast.com...
> I have a generic package that would benefit from doing some cleanup when
> an instantiation disappears.  It can't just declare a (private)
> Finalization_Controlled object because that would require all
> instantiations to be at library level.  Suggestions?

Re: Ada2005 again, was: non-library level finalization

[Randy Brukardt]

"Martin Dowie" <martin.dowie@baesystems.com> wrote in message
news:423edfb3$1_1@glkas0286.greenlnk.net...
> Tapio Kelloniemi wrote:
> > And in
> > general, is there some sort of summary which lists changes in Ada2005
> > (with references to corresponding AI's). I know where AI's are
> > stored, but there are quite many of them and looking through all of
> > them to just look up their summary line is quite a slow process.
> >
> > I have read the AdaCore's ada2005 page, but it is not accurate enough
> > and lists only major changes.
>
> I believe John Barnes is producing something but I know of no timescale.
>
> The AdaCore page is also (slightly) inaccurate - there isn't going to be a
> standard "socket" package.

The most recent draft of the Amendment document is available at
http://www.ada-auth.org/amendment.html. Also, the most recent (incomplete)
draft of the RM and AARM are on-line. They're supposedly not available to
the public (because they are incomplete), but since some search engines know
where they are, finding them isn't hard.

Of course, neither of these is a summary. The AARM includes "differences",
"extensions", and "incompatibilities" sections, so those could be used to
help create a summary.

                    Randy Brukardt, ARG Editor.

Re: non-library level finalization

[Randy Brukardt]

<tmoran@acm.org> wrote in message news:eIKdnT-oNJ6gvqPfRVn-pA@comcast.com...
> I have a generic package that would benefit from doing some cleanup when
> an instantiation disappears.  It can't just declare a (private)
> Finalization_Controlled object because that would require all
> instantiations to be at library level.  Suggestions?

I forgot the obvious. The problem is not with a controlled *object*, but
rather declaring a controlled *type*. So, you can do this by declaring a
controlled type outside of the generic. Now, to make that useful, you'd have
to figure out some way to figure out how to do the needed actions inside of
the generic -- and *that* might prove difficult depending on what you need
done. (For instance, registering a handler would work, but it too would have
to be at library-level -- so you wouldn't have gained anything.)

For a lot of generics, restricting to library level isn't a major concern
(or, it's happened already, as is usually the case for tagged types). But
your case may be different.

                              Randy.

Re: non-library level finalization

[tmoran]

>I forgot the obvious. The problem is not with a controlled *object*, but
>rather declaring a controlled *type*. So, you can do this by declaring a
>controlled type outside of the generic. Now, to make that useful, you'd have
>to figure out some way to figure out how to do the needed actions inside of
>the generic -- and *that* might prove difficult depending on what you need
>done. (For instance, registering a handler would work, but it too would have
>to be at library-level -- so you wouldn't have gained anything.)
  I considered the obvious
package Finalization_Helper is
  type Ptr_Type is access procedure;
  type Finalizer_Type is new Ada.Finalization.Limited_Controlled with record
    Last_Wishes_Ptr : Ptr_Type;
  end record;
  procedure Finalize(Finalizer : in out Finalizer_Type)  ...  is
  begin
    Finalizer.Last_Wishes_Ptr.all;
  exception
    when others=>null;
  end Finalize;

and then putting in the generic
  procedure Cleanup;
  Finalizer : Finalization_Helper.Finalizer_Type
    := (Last_Wishes_Ptr=>Cleanup'access);
but that has an access level problem.

>For a lot of generics, restricting to library level isn't a major concern
>(or, it's happened already, as is usually the case for tagged types). But
>your case may be different.
  It's merely unpleasing and maintenance error-prone to add an extra
package to instantiate the generic, and a Use clause to hide the fact of
the extra package.