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/08
Message-ID: <8f744h$s38$1@nnrp1.deja.com>#1/1
X-Deja-AN: 620764604
References: <390D94FB.D23390D4@lmco.com> <8eketr$i3c$1@nnrp1.deja.com>
 <3910514D.13BF2DE1@Raytheon.com> <8es7n2$7lk$1@nnrp1.deja.com>
 <3916D7F4.178B4FDE@Raytheon.com>
X-Http-Proxy: 1.0 x43.deja.com:80 (Squid/1.1.22) for client 205.232.38.14
Organization: Deja.com - Before you buy.
X-Article-Creation-Date: Mon May 08 19:22:12 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-08T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <3916D7F4.178B4FDE@Raytheon.com>,
  "Samuel T. Harris" <samuel_t_harris@Raytheon.com> wrote:

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

Well you can have any opinion you like. But unchecked conversion
is far better defined than overlay. The latter is completely
implementation defined, and may cause havoc due to descriptors
etc.

> Conversion of access types only works when the access types
> are in the same storage pool.

Good practice here is to use unchecked conversion only on
general access pointers which do NOT reference unconstrained
array types.

> 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 that unchecked conversion is far better
defined, better signalled in the sources (i.e. the use of
potentially unsafe techniques is better flagged to the reader),
and is far more likely to be portable than the use of address
overlays.


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

The extra stuff, and most particularly the "with

Unchecked_Conversion" in the context clause is welcome
to raise red flags. This is NOT the kind of thing we want
writers to do conveniently and inconspicuously.

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

You should use general access types, as indicated in my
examples.

> > I think I preferred the Ada 83 formulation.
>
> Do you mean "for b use at x'address;" ?

No, I mean the rule in Ada 83 that said that use of address
clauses to achieve overlays was always erroneous. The syntax
is neither here nor there.


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