Re: Unconstrained type Unchecked_Deallocation

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

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.