Unconstrained type Unchecked_Deallocation

Unconstrained type Unchecked_Deallocation

[Andy Askey]

I have a byte array type that is used to generate byte-arrays
dynamically.  I want to dynamically deallocate these byte-arrays. Can
I use the following to deallocate memory?

If not, any suggestions?

package tst_pkg is
  type Byte_Atype is array (integer range <>) of character;
  type Byte_Ptype is access Byte_Atype;

  procedure Free(The_Array : in out Byte_Ptype);
end tst_pkg;

package body tst_pkg is
  procedure Deallocate is new Ada.Unchecked_Deallocation(
        Byte_Atype, Byte_Ptype);

  procedure Free(The_Array : in out Byte_Ptype) is
  begin
     Deallocate(The_Array);
  end;
end tst_pkg;

The real question is will the Free procedure deallocate all the bytes
allocated with the following?

my_bytes : Byte_Ptype;
begin
   my_bytes := new Byte_Atype(1..100);
   tst_pkg.Free(my_bytes);
end;


Thanx. Andy
--
Andy Askey
ajaskey@mindspring.com

Re: Unconstrained type Unchecked_Deallocation

[Ted Dennison]

In article <38C3D82F.C9F81832@bton.ac.uk>,
  John English <je@bton.ac.uk> wrote:
> Ted Dennison wrote:
> > That ought to work just fine. However, I don't see the benifit of
> > doing this over just naming the instantiation of
> > Unchecked_Deallocation "Free" in the first place. They have the same
> > parameter profile and the same mission.
>
> Possibly to avoid creating a dependence between the package spec and
> Unchecked_Deallocation? Might make it easier to move to a different
> allocation/deallocation regime at a later date, e.g. when porting...

Assuming that in real life that code is split between the spec and
body? That's a good possiblity.

The best reason I could think of was the possibility that this is just
an example of a routine that in real life also needs to contain some
other cleanup code. But I find often with beginners they just don't know
any better, so its best to point out inefficencies and possible
alternate techniques.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Unconstrained type Unchecked_Deallocation

[Ted Dennison]

In article <lup5csoc69dj9ko2q7fbdduf8n0i4h09ll@4ax.com>,
  Andy Askey <ajaskey@mindspring.com> wrote:
> I have a byte array type that is used to generate byte-arrays
> dynamically.  I want to dynamically deallocate these byte-arrays. Can
> I use the following to deallocate memory?
> package tst_pkg is
>   type Byte_Atype is array (integer range <>) of character;
>   type Byte_Ptype is access Byte_Atype;
>
>   procedure Free(The_Array : in out Byte_Ptype);
> end tst_pkg;
>
> package body tst_pkg is
>   procedure Deallocate is new Ada.Unchecked_Deallocation(
>         Byte_Atype, Byte_Ptype);
>
>   procedure Free(The_Array : in out Byte_Ptype) is
>   begin
>      Deallocate(The_Array);
>   end;
> end tst_pkg;

That ought to work just fine. However, I don't see the benifit of doing
this over just naming the instantiation of Unchecked_Deallocation "Free"
in the first place. They have the same parameter profile and the same
mission.


> The real question is will the Free procedure deallocate all the bytes
> allocated with the following?
>
> my_bytes : Byte_Ptype;
> begin
>    my_bytes := new Byte_Atype(1..100);
>    tst_pkg.Free(my_bytes);
> end;

Of course. If not, your compiler is seriously broken!

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Unconstrained type Unchecked_Deallocation

[tmoran]

>> The real question is will the Free procedure deallocate all the bytes
>> allocated with the following?
>Of course. If not, your compiler is seriously broken!
  The real question is why the questioner started on the assumption
that Unchecked_Deallocation didn't work in a standard situation, but
but was happily accepted by the compiler in that situation.
  With most Ada compilers, it's better to start on the assumption
the compiler, as well as the language, was not designed by amateurs.
If you think something is broken, try it with a test program.  If
that proves it is in fact broken, then it's reasonable to ask (perhaps
on c.l.a.) if the error is in the compiler or the language.

Re: Unconstrained type Unchecked_Deallocation

[John English]

Ted Dennison wrote:
> That ought to work just fine. However, I don't see the benifit of doing
> this over just naming the instantiation of Unchecked_Deallocation "Free"
> in the first place. They have the same parameter profile and the same
> mission.

Possibly to avoid creating a dependence between the package spec and
Unchecked_Deallocation? Might make it easier to move to a different
allocation/deallocation regime at a later date, e.g. when porting...

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Unconstrained type Unchecked_Deallocation

[Robert Dewar]

In article <38C566CE.6283C0AD@rational.com>,
  Mark Lundquist <mark@rational.com> wrote:

> Right, hiding the instantiation of Unchecked_Deallocation is
> often a good idea.

This is stated without justification. Please give your reasons
for this, I don't see it at all.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Unconstrained type Unchecked_Deallocation

[Larry Kilgallen]

In article <8a6f5s$5st$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes:
> In article <38C566CE.6283C0AD@rational.com>,
>   Mark Lundquist <mark@rational.com> wrote:
> 
>> Right, hiding the instantiation of Unchecked_Deallocation is
>> often a good idea.
> 
> This is stated without justification. Please give your reasons
> for this, I don't see it at all.

These days I tend to name my instantiations of Unchecked_Deallocation
Unchecked_<something-or-other>.  The fact that an instantiation exists
is plain, and if I wanted to hide the instantiation it would give it
a scope larger than I want.

Re: Unconstrained type Unchecked_Deallocation

[Robert I. Eachus]

Robert Dewar wrote:
> 
> In article <38C566CE.6283C0AD@rational.com>,
>   Mark Lundquist <mark@rational.com> wrote:
> 
> > Right, hiding the instantiation of Unchecked_Deallocation is
> > often a good idea.
> 
> This is stated without justification. Please give your reasons
> for this, I don't see it at all.

   There are occaisions where you may want in the future to change the
management mechanism for
some type, by a means other than using storage pools.  However, in Ada
95 this seems like a long
stretch.  In any case, if the fact that a type is an access type is
visible--as it has to be to
do the instantiation, I don't see much reason to hide the deallocation
operation.

   Unchecked_Conversion is a very different case.  I think I invented
the name "Unchecked Perversion" for visible instantiations of
Unchecked_Conversion--it really is that bad.  Putting
an instance of Unchecked_Conversion substantially increases the coupling
throughout a program with no corresponding benefit.  As an example--and
one I ran into often in the early days of Ada--consider an unchecked
conversion as follows:

    type Foo is access Bar;
    function UC is new Unchecked_Conversion(Foo, Integer);

   Now try to port the code to an Ada implementation where Integer is 16
bits.  You think you 
can just redefine UC, but it is not that easy.  The worst horror of this
type I ever ran into
took over a week to rehide a public conversion between two "slightly
different" record layouts.
The most embarrassing part of that was that the initial author's intent
was to speed up access
by not using record variants, and the properly hidden code was
significantly faster.

Re: Unconstrained type Unchecked_Deallocation

[P. S. Norby]

Robert I. Eachus wrote:
> 

>    Unchecked_Conversion 
>  "Unchecked Perversion" 

I recall someone, in a presentation at SIGAda, mistakenly (?)
refering to it as "unchecked_confusion"!

P.S. Norby

 "Software engineers are, in many ways, similar to normal people"

        --  Scott Adams

"No excuses.  No embarrassment.  No apologies...
 Ada -- the most trusted and powerful programming language
 on earth, or in space." -- S. Tucker Taft
 
\\\    \\\    \\\    \\\    \\\    \\\    \\\    \\\    \\\ 
( :)   ( :)   ( :)   ( :)   ( :)   ( :)   ( :)   ( :)   ( :)
///    ///    ///    ///    ///    ///    ///    ///    /// 
(Speaking only for myself)

Re: Unconstrained type Unchecked_Deallocation

[Robert Dewar]

In article <38EBAAD6.3EA21F14@earthlink.net>,
  "Robert I. Eachus" <rieachus@earthlink.net> wrote:
>     type Foo is access Bar;
>     function UC is new Unchecked_Conversion(Foo, Integer);
>
>    Now try to port the code to an Ada implementation where
> Integer is 16
> bits.  You think you
> can just redefine UC, but it is not that easy.


This is complete nonsense as far as I am concerned. The
difficulty of conversion here is completely unaffected by
whether the unchecked conversion is in the body or in the
spec. In either case we have conversions that must be dealt
with, and the set of problems is identical in the two cases.

The *only* difference is in whether stuff has to be recompiled
or not, and even this does not apply if there is a pragma
Inline around. Otherwise it makes no semantic difference
AT ALL whether the UC is in the spec or body.

Calling it unchecked_perversion does not make an argument :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Unconstrained type Unchecked_Deallocation

[Robert I. Eachus]

Robert Dewar wrote:

> This is complete nonsense as far as I am concerned. The
> difficulty of conversion here is completely unaffected by
> whether the unchecked conversion is in the body or in the
> spec. In either case we have conversions that must be dealt
> with, and the set of problems is identical in the two cases.

   Sorry, it is completely different.   Say you have two types, at least
one of which is private,and an instantiation of Unchecked_Conversion in
the body
of the package defining the private type.  To be more specific:

   package Foo is

     type Foo_Type is private;
     function Create(Value: Integer) return Foo_Type;  -- Initially U_C
     ....

   end Foo;

   If at some later date it is necessary to change the conversion,
perhaps to
target a machine with a different word length, only the specification
and body of Foo will need to be modified.  (The package specification
will need
to be modified to change the declaration of Foo_Type--the function
declaration need not change.)

   Now let's try unchecked perversion:

   package Foo is
      type Foo_Type is private;
      function Create is new Unchecked_Conversion(Integer, Foo_Type);
      ...
   end Foo;

   Now if you need to make a change it is extremely hard.  The privacy
of Foo_Type has been completely lost, so any section of code can depend
on the equivalence of Integer and Foo_Type.  This includes, and this is
where the name
comes from, all units which can see Integer, even those without a with
clause for Foo. At a minimum, you end up having to inspect the source
for the entire
program just to estimate how much work is required to change the
representation of Foo_Type.  In the worst case, and I have run into a
couple, you end up paying the compiler vendor to provide, 32-bit
Integer, or 32-bit access types in response to a size clause, etc.

   The worst such unchecked perversions are those which convert between
two
predefined types--in Ada 83 days usually System.Address and
Standard.Integer.
There have been several occaisons where a quick review of the code
revealed this problem, and the solution was to force the choice of a
particular compiler, or
just to limit the possible choices.

   So yes, I do think that this is a very nasty thing to do, especially
when
avoiding the problem only requires a couple extra lines of code.

Re: Unconstrained type Unchecked_Deallocation

[Robert Dewar]

In article <38F0B641.2346CF95@earthlink.net>,
  "Robert I. Eachus" <rieachus@earthlink.net> wrote:
> Robert Dewar wrote:
>
> > This is complete nonsense as far as I am concerned. The
> > difficulty of conversion here is completely unaffected by
> > whether the unchecked conversion is in the body or in the
> > spec. In either case we have conversions that must be dealt
> > with, and the set of problems is identical in the two cases.
>
>    Sorry, it is completely different.

<<detailed discussion snipped>>

Your discussion boils down to worrying about a class of
programmers who have the following characteristics.

1. They would not dream of looking in a body, and taking
liberties with information derived therefrom.

2. They will look at an unchecked conversion in the spec and
feel free to do stupid things.

OK, maybe there are such programmers, but I have not met them.
I meet really two classes of programmes in this kind of respect.

1. Those who are careful, and know that it would be folly to
depend on the representational equivalence implied by an
unchecked conversion, whether or not it is in the spec or the
body.

2. Those who will do what they like, regardless of what is nice,
and will not hesitate a moment to draw the same (bad) conclusion
from an unchecked conversion in the body as in the spec.

I think trying to make this out as an important methodological
issue is bogus. After all, if you have a function in the spec
whose spec is that it convers from integer to address by the
moral equivalent of unchecked conversion, then you can draw
evil conclusions just from this spec. I cannot imagine some
wonderful high level semantic description of this conversion
that is at an abstraction level different from unchecked
conversion (assuming a reasonable implementation thereof).


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Unconstrained type Unchecked_Deallocation

[Robert I. Eachus]

Robert Dewar wrote:
  
> Your discussion boils down to worrying about a class of
> programmers who have the following characteristics.
> 
> 1. They would not dream of looking in a body, and taking
> liberties with information derived therefrom.
> 
> 2. They will look at an unchecked conversion in the spec and
> feel free to do stupid things.

  Yep, on a large project, if there is an unchecked conversion in the
interface, programmers
will assume that it is part of the interface and can be treated as
such.  These same programmers
may never have the opportunity to look at the corresponding body, which
may be written by a group at a different location, or even a different
company.  In fact, I have seen unchecked perversion where the specs were
common, and the bodies were written by two different companies several
thousand miles apart.  Moving to a different platform was a killer...
 
> OK, maybe there are such programmers, but I have not met them.

  The luxury of being an academic. ;-) That smiley is because Robert
Dewar has spent as much time in the trenches as I have.  I just used to
get called in on the really bad cases.  I literally can't tell you how
many times I have been called in to declare the corpse dead--and yes,
there have been a few times when it wasn't.  If I can I'd like to write
a paper on how to tell that a software project is dead.  In one
sentence, if fixing a bug will on average introduce at least one new
bug, stop.  The trick is to be able to determine that ahead of time, and
stop earlier.  (Or even on time.  It is a characteristic of failed
software projects that the quality of the bug report database is poor.)

> I meet really two classes of programmes in this kind of respect.
 
> 1. Those who are careful, and know that it would be folly to
> depend on the representational equivalence implied by an
> unchecked conversion, whether or not it is in the spec or the
> body.

    But would never dream of putting the Unchecked_Conversion in the
visible part of the package...
 
> 2. Those who will do what they like, regardless of what is nice,
> and will not hesitate a moment to draw the same (bad) conclusion
> from an unchecked conversion in the body as in the spec.

    But to make use of the fact, they often have to put in their own
instances of Unchecked_Conversion and get caught that way.
 
> I think trying to make this out as an important methodological
> issue is bogus. After all, if you have a function in the spec
> whose spec is that it convers from integer to address by the
> moral equivalent of unchecked conversion, then you can draw
> evil conclusions just from this spec. I cannot imagine some
> wonderful high level semantic description of this conversion
> that is at an abstraction level different from unchecked
> conversion (assuming a reasonable implementation thereof).

     No, the conclusions that you can draw from the function in the spec
are not evil.  If for example the body of a visible conversion function
is an instance of Unchecked_Conversion from Integer to System.Address,
and the program is moved to a different platform where the two have
different sizes, then it will usually be possible to replace that body
without changing the semantics.  (Of course there will normally be more
than one operation in the package that needs to be rewritten.  But
still, you are within one package body, and don't have to look
throughout the program.)