Re: Overlay allowability

["Samuel T. Harris" <samuel_t_harris@Raytheon.com>]

Robert Dewar wrote:
> 
> In article <3910514D.13BF2DE1@Raytheon.com>,
>   "Samuel T. Harris" <samuel_t_harris@Raytheon.com> wrote:
> 
> > Many times the need for such overlays is a continual need
> > throughout a section of code. Several calls to
> > unchecked_conversion
> > is simply to slow and does present a consistency problem
> > associated with having two separate objects instead of two
> > overlayed objects. This consistency problem can be exploited
> > in a tasking environment and cause unpredictable results.
> 
> I think that's a potentially misleading response.
> It refers to an obvious
> misuse of unchecked conversion. The proper way to do this UC
> is to convert between the access types *ONCE* and then reference
> the view you want through the appropriate access type. This will
> typically give pretty much identical code to the use of an
> address overlay, so there is no efficiency issue.

The poster wasn't asking about UCing the pointers.
The question was about UCing the data vs making an overlay.
UCing pointers an another way to make overlays which are
IMO less clear to the reader than a address clause.

Conversion of access types only works when the access types
are in the same storage pool. What happens when one access type
is in a user-defined storage pool and such an unchecked_conversion
is performed? Better yet, what happens when both are in separate
storage pools?

> 
> > So, when performance and consistency are the requirements,
> > make an overlay. If one simply needs to jam one kind of data
> > into another, use unchecked_conversion.
> 
> This advice is to be dubious, because as above
> it is based on the wrong approach to using unchecked conversion.
> In fact, in practice in Ada 95, there is likely very little
> difference between the following:

Just what is dubious about this advice.
You are simpy defining two additional way to define an overlay
yet you make no comment on the deciding factor! The deciding
factor is the crucial part of my comment. As to the mechanics
of overlays, there are many ways to achieve the desired results
in Ada 95.

> 
>    type a is ...
>    type b is ...
> 
>    AV : aliased a;
>    BV : aliased b;
>    for BV'Address use AV'Address;
>    -- your compiler may make you define a constant for this
>    -- address making this a bit less convenient to use.

I can't see why this is preferable over a straight address
clause of objects of a and b. Besides, when the needs comes,
often times one or the other object is already declared.
Therefore AV or BV, as appropriate, will have to be setup
to point to the already declared object. Seems like a lot
of extra stuff when one address clause is needed.

> 
> and
> 
>    type a is ...
>    type a_Access is access all a;
>    type b is ...
>    type b_Access is access all b;
> 
>    function To_b_Access is new UC (a_Access, b_Access);
> 
>    AV : aliased A;
>    BVA : constant b_Access := To_b_Access (AV'Access);
>    BV : B renames BVA.all;

Also, a lot of extra stuff when a single address clause
is called for. I don't see the advantage of these indirect
views. Also, is a_Access and/or b_Access are allocated
to user defined storage pools, then isn't this going to 
create problems?

> 
> In practice, if the types are records or arrays, you can
> probably shorten this to:
> 
>    BV : constant b_Access := To_B_Access (AV'Access);
> 
> and use automatic dereferencing.
> 
> Which to prefer?
> 
> The use of UC is to me clearer, and has the advantage of the
> loud "with Unchecked_Conversion" in the context clause
> indicating a unit that is suspect and potentially unsafe.
> 
> The danger of the address overlay is that it is far too easy
> to sneak this in. I have even seen things like:
> 
>    x : integer;
>    b : integer;
>    for b'address use x'address;
> 
> to achieve the effect of a simple renaming, and that clearly
> represents running amok with address overlays :-)

Yes, the above is silly!
That is what code rule checkers are for.

> 
> I think I preferred the Ada 83 formulation.

Do you mean "for b use at x'address;" ?

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

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"