Unchecked Deallocation?

Unchecked Deallocation?

[Caffeine Junky]

I think I'm getting a handle on using Unchecked Deallocation. However
I'm running into a problem. In my spec file I have these types defined...

with unchecked_deallocation;

generic
  type Item is private;

package genstack is 	-- A basic generic stack. Singlely linked list. --

        type stack is limited private;
        ...  -- Some other procedures defined here. --       
	function Clear_Stack(S : in Stack) return Boolean;


private

	type Cell;
	type stack is access Cell;
	type Cell is record
	   Value: Item;
	   Next: Stack;
	end record;

end genstack;


Now in the body of the package I have this...

package body genstack is

	procedure Free is new Unchecked_Deallocation(Cell, Stack);

	.....	-- Some other procedures here  --

	function Clear_Stack(S : in Stack) return Boolean is -- Return True or
													 -- or False if the
													 -- operation succeeded. --

	begin

	  Free(Stack);
	  return True;	   -- No reason for it not to return True in this --
				   -- instance, as far as I can tell.             --
        end Clear_Stack;

end genstack;

Now, when attempting to compile the code, I get this...

	41. Free(Stack)
	         |
        >>> Invalid use of subtype mark in expression or call
        >>> actual for 'X' must be a variable

I'm using Gnat 3.14p (Debian)


Now, as far as I can tell, I cannot give it an actual variable because
Cell is defined in the private type and is only accessible via the
'Stack' pointer variable. I dont think even Aliases can get past this
rule.
Also, the Unchecked_Deallocation documentation in the LRM that came with
GNAT (found it using GNU Info) shows Unchecked_Deallocation being
instantiated just the way I did it here.(Assuming I understood the docs.)
As does my "Programming in Ada95" book by John Barnes.
I suspect that it needs access to the Cell variable declared in the
private section, but I'm not sure how to do that safely.

Any pointers would be appreciated.

St4pL3

Re: Unchecked Deallocation?

[Robert A Duff]

Caffeine Junky <nospam@hotmail.com> writes:

> 	function Clear_Stack(S : in Stack) return Boolean;

You want a procedure, here, with an 'in out' parameter.  Not a function.
You need to recursively free the whole list.
Your instantiation of Unchecked_Deallocation is correct.

> 	  return True;	   -- No reason for it not to return True in this --
> 				   -- instance, as far as I can tell.             --

Right, which is why you don't want a function.

- Bob

Re: Unchecked Deallocation?

[Caffeine Junky]

On Fri, 12 Jul 2002 19:12:50 -0400, Robert A Duff wrote:

> Caffeine Junky <nospam@hotmail.com> writes:
> 
>> 	function Clear_Stack(S : in Stack) return Boolean;
> 
> You want a procedure, here, with an 'in out' parameter.  Not a function.
> You need to recursively free the whole list. Your instantiation of
> Unchecked_Deallocation is correct.
> 
>> 	  return True;	   -- No reason for it not to return True in this --
>> 				   -- instance, as far as I can tell.             --
> 
> Right, which is why you don't want a function.
> 
> - Bob
 
I get it! I really actually GET IT! For a change. And it works.

I seem to have an affinity for functions, and I dont know why. Any
rules of thumb on when it's a good idea to (use/not use)
functions and procedures in Ada95?

I'm also checking out Mr. Botton's example on 'Garbage Collection' over
at the Adapower website. Seems that taking that route might be simpler in
some regards.

Any good Ada references on memory managment you can point me to?

Thanks.

St4pL3

Re: Unchecked Deallocation?

[R. Tim Coslet]

Think of Procedures as "Commands": they do things and can change the state
of variables.

Think of Functions as "Queries": they calculate and look up things, but are
not allowed to change the state of variables.

That slightly oversimplifies it, but it is the "basic" difference between
the two in Ada.

-- 
        R. Tim Coslet
        r_tim_coslet@pacbell.net

Technology, n. Domesticated natural phenomena.


> From: Caffeine Junky <nospam@hotmail.com>
> Organization: AT&T Broadband
> Newsgroups: comp.lang.ada
> Date: Sat, 13 Jul 2002 00:52:34 GMT
> Subject: Re: Unchecked Deallocation?
> 
> 
> I seem to have an affinity for functions, and I dont know why. Any
> rules of thumb on when it's a good idea to (use/not use)
> functions and procedures in Ada95?

Re: Unchecked Deallocation?

[tmoran]

> with unchecked_deallocation;
> generic
> type Item is private;
>package genstack is     -- A basic generic stack. Singlely linked list. --
  You needn't 'with' unchecked_deallocation here since you never use it
in the package spec.  It's only used in the body, so you could move this
'with' there.  BTW, "Unchecked_Deallocation" is obsolescent Ada 83 naming.
It's not much more typing, and might save someone a headache in the future,
to use the modern form "Ada.Unchecked_Deallocation".

>       procedure Free is new Unchecked_Deallocation(Cell, Stack);
>       function Clear_Stack(S : in Stack) return Boolean is -- Return True or
>       begin
>         Free(Stack);
                 |
        >>> Invalid use of subtype mark in expression or call
        >>> actual for 'X' must be a variable
  What particular stack might you possibly mean to free?  If your program
used pointers to integers, would you say "Free(Integer)" when you wanted
to get rid of one?  You need, as the error message said, to call Free with
the name of a particular stack to free, presumably S in this case, not the
name of a type.  Since the parameter to Free is "in out", S will have
to be "in out", which means Clear_Stack can't be a function (as previously
pointed out).  A function that always returns the same value is not much
of a function, anyway.  And as pointed out, you probably don't really
just want to deallocate the single cell, but rather a whole list of them.
Calling a pointer to a cell a stack sets you up for this confusion.
You have three different kinds of entities: a data-containing cell,
a pointer to such a cell, and a list of related cells.  Better to use
three different names for three different things.

> Cell is defined in the private type and is only accessible via the
  The private part of a package spec *is* visible to the body of that
package, just not visible to other packages.  If it was not visible
to *any* package body it would be of mighty limited utility.

Re: Unchecked Deallocation?

[Caffeine Junky]

On Fri, 12 Jul 2002 22:31:24 -0400, tmoran wrote:


>   What particular stack might you possibly mean to free?  If your
>   program
> used pointers to integers, would you say "Free(Integer)" when you wanted
> to get rid of one?  You need, as the error message said, to call Free
> with the name of a particular stack to free, presumably S in this case,
> not the name of a type.  Since the parameter to Free is "in out", S will
> have to be "in out", which means Clear_Stack can't be a function (as
> previously pointed out).  A function that always returns the same value
> is not much of a function, anyway.  And as pointed out, you probably
> don't really just want to deallocate the single cell, but rather a whole
> list of them. Calling a pointer to a cell a stack sets you up for this
> confusion. You have three different kinds of entities: a data-containing
> cell, a pointer to such a cell, and a list of related cells.  Better to
> use three different names for three different things.

Your right. That little error in my logic came to light when I was fixing
the program. I'll need to pay better attention to what I'm doing from now
on.
 
>> Cell is defined in the private type and is only accessible via the
>   The private part of a package spec *is* visible to the body of that
> package, just not visible to other packages.  If it was not visible to
> *any* package body it would be of mighty limited utility.
 
   That much is certain.

   Guess I'll be brushing up on access values and data types tonight. :-p

Thanks for the pointers.(No pun intended.)

St4pL3