How does this look?

How does this look?

[Caffeine Junky]

I did a little simplifying of my genstack package.(Generic Stack)
I got rid of Unchecked_Deallocation(although it will be going back in as
I tune the package a little better.)

There shouldn't be any memory leaks this time.


generic
	Max : Positive;
	type Item is private;

package safer_genstack is

	type Stack is limited private;

	procedure Push(X : in Item; S : in out Stack);
	procedure Pop(S : in out Stack; X : out Item);
	
private

	type Cell;
	type Stack is access Cell;
	type Cell is record
		Value : Item;
		Next : Stack;
	end record;
	
	for Stack'Storage_Size use Cell'Max_Size_In_Storage_Elements * Max;

end safer_genstack;

With this one, notice, I didnt have to fool around with
Unchecked_Deallocation. Nor is there a need for an explicit Allocator or
an 'Is_Empty' function to see if anythings still there. That 'Max'
variable comes in handy.

package body safer_genstack is
	

	procedure Push(X : in Item; S : in out Stack) is

	begin

	  S := new Cell'(X, S);

	end Push;

	procedure Pop( S : in out Stack; X : out Item) is

		Local : Item;

	begin

		Local := S.Value;
		S := S.Next;
		X := Local;

	end Pop;

end safer_genstack;

I do believe I'm starting to get the hang of it.

Now I'll have to start doing extra checks to make sure the program isn't
trying to access memory that isn't there anymore. Aaah, the joys.

Anyone care to critique a novice. I'm all ears.


St4pL3

Re: How does this look?

[tmoran]

> How does this look?
You might first ask your compiler.

Re: How does this look?

[Caffeine Junky]

On Sat, 13 Jul 2002 23:49:30 -0400, tmoran wrote:

>> How does this look?
> You might first ask your compiler.
 
It compiled into an object file without any errors. Guess I'm overlooking
something.

St4pL3

Re: How does this look?

[tmoran]

> > You might first ask your compiler.
>
> It compiled into an object file without any errors. Guess I'm overlooking
> something.

I suspect you didn't try a little dummy program that instantiates
safer_genstack.  Some compilers wait till you try to instantiate before
they complain about
        for Stack'Storage_Size use Cell'Max_Size_In_Storage_Elements * Max;
appearing too late.

Re: How does this look?

[Caffeine Junky]

On Sun, 14 Jul 2002 03:09:00 -0400, tmoran wrote:

>> > You might first ask your compiler.
>>
>> It compiled into an object file without any errors. Guess I'm
>> overlooking something.
> 
> I suspect you didn't try a little dummy program that instantiates
> safer_genstack.  Some compilers wait till you try to instantiate before
> they complain about
>         for Stack'Storage_Size use Cell'Max_Size_In_Storage_Elements *
>         Max;
> appearing too late.
 
Hmmm....you do make a good point.

I tried 
	
	S'Size := Cell'Max_Size_in_Storage_Elements * Max;

in the body of the package and I get this...

	S'Size := Cell'Max_Size_in_Storage_Elements * Max;
	|
     >>>Declaration Expected

which seems pretty redundant as S is already declared in the spec file.

You know, I didnt have much trouble with other segments of Ada(so far),
but Storage Pools are really starting chaffe my ass. It seems like I
could re-declare the same variable a dozen times in each of a dozen
different packages of a program, and the compiler would still keep asking
me to re-declare it. S WAS ALREADY DECLARED! The only thing I can chalk
it up to is a bug in the compiler, either it's giving false errors or the
error message needs to be re-written to make sense.

Please be patient, I'm a little tired and cranky after going over this
for the 137th time.


Anyways, thanks.

St4pL3

Re: How does this look?

[martin.m.dowie]

"Caffeine Junky" <nospam@hotmail.com> wrote in message
news:_DcY8.524447$cQ3.46097@sccrnsc01...
> You know, I didnt have much trouble with other segments of Ada(so far),
> but Storage Pools are really starting chaffe my ass. It seems like I
> could re-declare the same variable a dozen times in each of a dozen
> different packages of a program, and the compiler would still keep asking
> me to re-declare it. S WAS ALREADY DECLARED! The only thing I can chalk
> it up to is a bug in the compiler, either it's giving false errors or the
> error message needs to be re-written to make sense.

The problem isn't in the storage pools but in the declaration you have for
Cell - try
going back to it, maybe after some sleep ;-)

The phrase ">>>Declaration Expected" isn't asking you to add yet another
declaration,
but rather that what you provided *isn't* a declaration. "S'Size" is a
function call (although
it might not look like it). See LRM Annex K.

http://www.adaic.org/standards/95lrm/html/RM-K.html

Re: How does this look?

[tmoran]

> in the body of the package and I get this...
>
>         S'Size := Cell'Max_Size_in_Storage_Elements * Max;
>         |
>      >>>Declaration Expected
>
> which seems pretty redundant as S is already declared in the spec file.
  There is no "S" in the safer_genstack spec file you posted.  There is an
S which is a parameter in the Push procedure, and another S which is a
parameter in Pop.
  Since you are getting "declaration expected", the compiler probably
thinks it's seeing an assignment statement, but in a declarative
area (before the "begin").
  When you move it, you will get another error since S'Size gives the
size of S, and thus can appear on the right side of an assignment
statement, but it doesn't let you change the size of S, which appears
to be what you are trying to do.  If a program called Push, say, with
an S that was a 32 bit pointer, and Push changed the size of S to
something else, it would take truly complicated code to handle.
If Push could change the size of the storage pool, what would happen
if it shrank the pool to a size too small for the current data - would
you want Storage_Error raised?  Would you disallow shrinking?  If
the pool could be expanded, how would using it differ from just using
a portion of the default heap, not using a special pool at all?
  If you are trying to create a separate Storage_Pool just for stacks,
of size Cell'Max_Size_in_Storage_Elements * Max, why not simplify life
and just make a stack an array of Max Items plus a Current_Top_Of_Stack
index?  Usually if you want a specific, known, amount of memory it's
best to use an array or record.  One usually uses the heap ("new ...")
when you don't know exactly how your total storage needs will divide
up among various things, or when your needs are dynamic in size, eg,
when you don't want a fixed Max.

Re: How does this look?

[Caffeine Junky]

Basically, I'm working at learning a bunch of different ways of handling
memory. Storage Pools is one among many. An Indexed array is another.
Using Unchecked_Deallocation on everything is yet another(although not
necessarily the wisest)way.
Memory leaks are also a pet peeve of mine. Hence I'm making it a point to
try and become skilled at correctly handling the memory issues of my
software without screwing up.

Different methods work best for different problems. Sure, I could
implement an array of access variables to records or other arrays, and
have that variable and associated structure de-allocated when it's no
longer referenced/goes out of scope. And I will implement some lists this
way for practice. But I'm also learning how to use storage pools, because
eventually they'll come in handy.


Thanks for your help. I'm doing a bit more homework. I'll repost it once
I got something that works.


St4pL3

Re: How does this look?

[Simon Wright]

Caffeine Junky <nospam@hotmail.com> writes:

> Basically, I'm working at learning a bunch of different ways of
> handling memory. Storage Pools is one among many. An Indexed array
> is another.  Using Unchecked_Deallocation on everything is yet
> another(although not necessarily the wisest)way.

Of course if you use a storage pool you still say new and
Unchecked_Deallocation. And you can just as easily get garbage.