Re: Unconstrained type Unchecked_Deallocation

["Robert I. Eachus" <rieachus@earthlink.net>]

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.