"Inefficiency" of controlled types

"Inefficiency" of controlled types

[Matthew Heaney]

I'm curious about early in a derivation tree controlled types should be
introduced, given that there is some overhead in their use.

For example, suppose I have a stack type

with Ada.Finalization;
packages Stacks_G is

   type Root_Stack is abstract tagged private;
...
private

   type Root_Stack is
      new Ada.Finalization.Controlled with null record;

end Stacks_G;

In this formulation, Controlled is introduced at the root of the tree. 
This makes it very convenient for derived types, because they can just plug
in their own version of Finalize, and no component wrappers are necessary.

However, we really only need this for unbounded forms, which use heap
allocation.  For bounded forms (implemented as an array), finalization is
not really required, and so there is an "unnecessary" amount of overhead.

We don't have to introduce Controlled that early in the hierarchy.  Clients
that need it could declare a Controlled wrapper for that stack component
that requires finalization (say, a list component used to implement the
unbouned stack).

My question for the language designers is, Which is the preferred
technique?  Introduction of Controlled at the root, or locally at a branch? 
Does introduction at the root add "too much" inefficiency, or are
"unnecessary" calls optimized away?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: "Inefficiency" of controlled types

[Simon Wright]

mheaney@ni.net (Matthew Heaney) writes:

> with Ada.Finalization;
> packages Stacks_G is
> 
>    type Root_Stack is abstract tagged private;
> ...
> private
> 
>    type Root_Stack is
>       new Ada.Finalization.Controlled with null record;
> 
> end Stacks_G;

This is a slightly different set of questions from Matthew's:

What happens if I derive a type from Root_Stack and declare a
primitive subprogram Finalize?

Does it make a difference if the package in which I do the derivation
is a child of Stacks_G?

It seems intuitive to me that I need to expose the derivation from
Controlled in the public part of Stacks_G if Finalize is to behave as
expected; but there was that long thread recently about visibility of
components and (as I recall) operations which might indicate
differently (or even, in the case of child packages, that there was no
point in my doing so!)

Seems to me that if the type is controlled I should make it visibly
so, so that users know that I need finalization and can arrange to
call my Finalize (Initialize, Adjust) from theirs.

The rule I've adopted is to say

  My_Type is new Ada.Finalization.Controlled with private;

and then in the private part to derive from the type whose eventual
root is Controlled.

-- 
Simon Wright                        Work Email: simon.j.wright@gecm.com
GEC-Marconi Radar & Defence Systems            Voice: +44(0)1705-701778
Command & Information Systems Divsion            FAX: +44(0)1705-701800

Re: "Inefficiency" of controlled types

[David S. Gibson]

Matthew Heaney wrote:
> 
> I'm curious about early in a derivation tree controlled types should be
> introduced, given that there is some overhead in their use.

  . . . 
  
> However, we really only need this for unbounded forms, which use heap
> allocation.  For bounded forms (implemented as an array), finalization is
> not really required, and so there is an "unnecessary" amount of overhead.
> 
> We don't have to introduce Controlled that early in the hierarchy.  Clients
> that need it could declare a Controlled wrapper for that stack component
> that requires finalization (say, a list component used to implement the
> unbouned stack).

When I was using controlled types for the same purpose, I found that I
had to
derive generic components from Ada.Finialization.Limited_Controlled at
the
root level due to the accessibility rules of Ada.  If I recall
correctly, an 
instance of a generic controlled type package needs to be declared as a 
library-level package.  While I put the derivation from
Limited_Controlled in
the private part, I would have liked to move it down some in the
hierarchy.

Dave
--
dgibson@cis.ohio-state.edu

Re: "Inefficiency" of controlled types

[Tucker Taft]

Simon Wright (simon@pogner.demon.co.uk) wrote:

: mheaney@ni.net (Matthew Heaney) writes:

: > with Ada.Finalization;
: > packages Stacks_G is
: > 
: >    type Root_Stack is abstract tagged private;
: > ...
: > private
: > 
: >    type Root_Stack is
: >       new Ada.Finalization.Controlled with null record;
: > 
: > end Stacks_G;

: This is a slightly different set of questions from Matthew's:

: What happens if I derive a type from Root_Stack and declare a
: primitive subprogram Finalize?

: Does it make a difference if the package in which I do the derivation
: is a child of Stacks_G?

Yes.  Only if the fact that Root_Stack is controlled is visible can
you override its finalize operation (which was in turn inherited
from Controlled).  This would be visible in the child (in its
private part), but not in some unrelated unit.

: It seems intuitive to me that I need to expose the derivation from
: Controlled in the public part of Stacks_G if Finalize is to behave as
: expected; but there was that long thread recently about visibility of
: components and (as I recall) operations which might indicate
: differently (or even, in the case of child packages, that there was no
: point in my doing so!)

: Seems to me that if the type is controlled I should make it visibly
: so, so that users know that I need finalization and can arrange to
: call my Finalize (Initialize, Adjust) from theirs.

That is true if you want the user to override your Finalize, but
also call it as part of theirs.  However, see below...

: The rule I've adopted is to say

:   My_Type is new Ada.Finalization.Controlled with private;

: and then in the private part to derive from the type whose eventual
: root is Controlled.

This works, but I think it is less robust than making individual 
components clean up after themselves.  When you add additional components
via type extension, and some of those components need some cleanup
action, then those components should themselves be controlled, rather
than moving the Finalize operation up to the enclosing type.
In this way it makes no difference how the type being extended
was implemented, or whether it is derived from Controlled.
The only time I would make a type visibly derived from Controlled
is when there is a clear semantic action (over and above storage
reclamation) that the type and all its extensions should associate 
with the end of an object's lifetime.  For example, a windowing system
might define that Finalize should do some special thing, such as erasing
the window, or whatever.  In this case, making the type visibly
derived from Controlled might make sense (though even then, it might
be better to have some other operation, and have the root type's
Finalize redipatch to this other operation).

This is a style issue, of course...

: -- 
: Simon Wright                        Work Email: simon.j.wright@gecm.com
: GEC-Marconi Radar & Defence Systems            Voice: +44(0)1705-701778
: Command & Information Systems Divsion            FAX: +44(0)1705-701800

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA