From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_00,INVALID_MSGID,
	MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,ab36006a122bb868
X-Google-Attributes: gid103376,public
From: Robert Dewar <robert_dewar@my-deja.com>
Subject: Re: Overlay allowability
Date: 2000/05/04
Message-ID: <8es7n2$7lk$1@nnrp1.deja.com>#1/1
X-Deja-AN: 619186419
References: <390D94FB.D23390D4@lmco.com> <8eketr$i3c$1@nnrp1.deja.com>
 <3910514D.13BF2DE1@Raytheon.com>
X-Http-Proxy: 1.0 x33.deja.com:80 (Squid/1.1.22) for client 205.232.38.14
Organization: Deja.com - Before you buy.
X-Article-Creation-Date: Thu May 04 16:15:49 2000 GMT
X-MyDeja-Info: XMYDJUIDrobert_dewar
Newsgroups: comp.lang.ada
X-Http-User-Agent: Mozilla/4.61 [en] (OS/2; I)
Date: 2000-05-04T00:00:00+00:00
List-Id: <comp.lang.ada>

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.

> 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:

   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.

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;

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 :-)

I think I preferred the Ada 83 formulation.



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