Why people wants to complicate code with Ada.Unchecked_Deallocation?

Why people wants to complicate code with Ada.Unchecked_Deallocation?

[fabio de francesco]

Hi all.

The following statement is from Cohen's "Ada as a second language":

"Ada.Unchecked_Deallocation must be used with caution. As we shall see, it
can lead to subtle but devastating errors. If storage for allocated object
is plentiful, there is no point in complicating the program to keep track
of which allocated objects are no longer needed".

Does it mean that, for safety sake, programmers should not care about memory
consumption? 

I am not sure I can agree with that. I've been tought that any "malloc"
and "new" must be followed by "free" and "delete". 

What do you think about this issue?

fabio de francesco

Re: Why people wants to complicate code with Ada.Unchecked_Deallocation?

[Georg Bauhaus]

On Wed, 2006-07-26 at 21:34 +0200, fabio de francesco wrote:
>  "If storage for allocated object
> is plentiful,...

> Does it mean that, for safety sake, programmers should not care about memory
> consumption? 

A program, run once an hour, to see how many new items have
been added to a database, report the number, and be done,
may well leave memory management to the system facilities IMHO.

That's safe, too, because I can't pass the wrong pointer
to an Unchecked_Deallocation.

Re: Why people wants to complicate code with Ada.Unchecked_Deallocation?

[Simon Wright]

fabio de francesco <cancella.fabiomdf@alice.elimina.it> writes:

> The following statement is from Cohen's "Ada as a second language":
>
> "Ada.Unchecked_Deallocation must be used with caution. As we shall
> see, it can lead to subtle but devastating errors. If storage for
> allocated object is plentiful, there is no point in complicating the
> program to keep track of which allocated objects are no longer
> needed".

In my world, storage is not plentiful, so we absolutely must keep
track of it! (but I certainly would _not_ bother over-much for an
off-line tool that runs to completion and isn't a heavy memory user
anyway).

Re: Why people wants to complicate code with Ada.Unchecked_Deallocation?

[Jeffrey R. Carter]

fabio de francesco wrote:
> 
> The following statement is from Cohen's "Ada as a second language":
> 
> "Ada.Unchecked_Deallocation must be used with caution. As we shall see, it
> can lead to subtle but devastating errors. If storage for allocated object
> is plentiful, there is no point in complicating the program to keep track
> of which allocated objects are no longer needed".
> 
> Does it mean that, for safety sake, programmers should not care about memory
> consumption? 
> 
> What do you think about this issue?

It means that if a program won't run out of storage without unchecked 
deallocation, why bother putting it in? On the other hand, if a program 
will run out of storage without unchecked deallocation, it will fail 
unless you do deallocate storage, so you probably do want and need to 
put it in.

In most cases, the use of access types and values can be hidden, so the 
opportunity for "devastating errors" is limited and not as big a concern 
as in C, where allocation and deallocation are usually scattered 
throughout the code. With the use of controlled types automatically 
performing deallocation during finalization, the opportunities for 
errors is limited further. So, in practice, it's not really that big of 
an issue.

-- 
Jeff Carter
"My mind is a raging torrent, flooded with rivulets of
thought, cascading into a waterfall of creative alternatives."
Blazing Saddles
89

Re: Why people wants to complicate code with Ada.Unchecked_Deallocation?

[Peter C. Chapin]

fabio de francesco wrote:

> What do you think about this issue?

It seems to me that in library units you pretty much have to use 
Unchecked_Deallocation because you don't know much about the memory 
requirements or constraints of the calling application. However, if you 
are creating an abstract data type and you hide the deallocation in a 
Finalize procedure, you probably aren't going to have a lot of trouble.

Peter

Re: Why people wants to complicate code with Ada.Unchecked_Deallocation?

[gautier_niouzes]

fabio:
[...]
> Does it mean that, for safety sake, programmers should not care about memory
> consumption?
>
> I am not sure I can agree with that. I've been tought that any "malloc"
> and "new" must be followed by "free" and "delete".
>
> What do you think about this issue?

I'm rather of your opinion.
If you start leaving memory leaks all around units it can become very
annoying as the projects grow and age.
You cannot predict if the target system will be plentiful enough to
absorb possible leaks or how long or on which input data size the
program will run.
It can happen that the pollution size at time t is a power of t times a
power of input data units or something like that...

IMHO it's a fully cultural problem.
Some people have tendency to say "just buy more storage, it's cheap",
other prefer to keep control of the rubbish...

Gautier
______________________________________________________________
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Why people wants to complicate code with Ada.Unchecked_Deallocation?

[adaworks]

"Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> wrote in message 
news:P7Rxg.1101345$xm3.664765@attbi_s21...
>
> It means that if a program won't run out of storage without unchecked 
> deallocation, why bother putting it in? On the other hand, if a program will 
> run out of storage without unchecked deallocation, it will fail unless you do 
> deallocate storage, so you probably do want and need to put it in.
>
I usually agree with you Jeff.  In this case, we are in close agreement
except on one point.   Ada includes a storage-pool capability that
allows for a wide range of storage management policies.  I would
expect that to be a better option in situations where there is a concern
for dependable, predictbale storage management.

That being said, I also find it uncommon for Ada designers to understand
the storage-pool feature well enough to take advantage of it.  Perhaps
we need to put together a collection of storage pool management
examples demonstrating how this feature of the language can be
more effectively applied in a variety of circumstances.   This could
reduce the amount of unchecked operations on storage management.

I am now wondering what storage management policies are used for
the Charles libraries.   Unchecked-deallocation?

Richard Riehle 

Re: Why people wants to complicate code with Ada.Unchecked_Deallocation?

[Jeffrey R. Carter]

adaworks@sbcglobal.net wrote:
>>
> I usually agree with you Jeff.  In this case, we are in close agreement
> except on one point.   Ada includes a storage-pool capability that
> allows for a wide range of storage management policies.  I would
> expect that to be a better option in situations where there is a concern
> for dependable, predictbale storage management.

That's another way to deallocate storage without all the opportunities 
for errors commonly found in languages like C. If your uses of access 
types and values are hidden, as is generally good practice, then so will 
be your storage pool. To the clients of the abstraction, it's invisible 
and probably makes no difference which you use.

> That being said, I also find it uncommon for Ada designers to understand
> the storage-pool feature well enough to take advantage of it.  Perhaps
> we need to put together a collection of storage pool management
> examples demonstrating how this feature of the language can be
> more effectively applied in a variety of circumstances.   This could
> reduce the amount of unchecked operations on storage management.

In addition, in practice, it's usually more complex than controlled 
types doing unchecked deallocation on finalization. Such examples would 
be a good addition to the Ada pedagogical collection.

-- 
Jeff Carter
"Perfidious English mouse-dropping hoarders."
Monty Python & the Holy Grail
10

Re: Why people wants to complicate code with Ada.Unchecked_Deallocation?

[Simon Wright]

<adaworks@sbcglobal.net> writes:

> That being said, I also find it uncommon for Ada designers to
> understand the storage-pool feature well enough to take advantage of
> it.  Perhaps we need to put together a collection of storage pool
> management examples demonstrating how this feature of the language
> can be more effectively applied in a variety of circumstances.  This
> could reduce the amount of unchecked operations on storage
> management.

I don't see how having a storage pool of your own affects the need for
unchecked deallocation? If your user wants to return the memory to
your special pool she still has to use deallocation!

I see in
http://www.adapower.com/index.php?Command=Class&ClassID=Advanced&CID=218
that Matt used 'storage pool' in a non-Ada sense, ie list of available
entities, in that case tasks.

http://en.wikibooks.org/wiki/Ada_Programming/Types/access might be a
good place for storage pool examples?

Re: Why people wants to complicate code with Ada.Unchecked_Deallocation?

[Robert A Duff]

Simon Wright <simon@pushface.org> writes:

> I don't see how having a storage pool of your own affects the need for
> unchecked deallocation? If your user wants to return the memory to
> your special pool she still has to use deallocation!

If you have a lot of objects with similar lifetimes, you can put them
all together in one pool, and deallocate the whole pool at once,
at the appropriate time.  Presuming you have a storage pool type
that knows how to do that, of course.

This is sometimes safer than deallocating them one by one, because you
have fewer places where you need to worry about "when is it safe to
deallocate?", and because you can't forget to deallocate some of the
individual objects.  It sometimes less safe, though, because you might
throw the baby out with the bathwater.  It depends on the program.

It's a very efficient way to manage storage.  Allocation can be just a
few instructions per object, and deallocation can be a small fraction of
one instruction per object.

- Bob