Re: Overlay allowability

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

Robert Dewar wrote:
> 
> 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.

As one who has done a lot of Ada 83, done some Ada 95 at
home, and am waiting for my work environment to move to Ada 95,
I am still being guided toward newer forms for the same
old issues. Robert, the details in your clarrifying response
now convince me the UC pointers is, in general, better
than an overlay. I hope that method is applicable to the
original poster! (I still think and address clause is
more readable than your stuff, but better defined is
to be preferred over simplicity.)

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

You still haven't address my case where the source object
is already defined. If it is not defined as aliased and
I have no control over it, then would you advocate an UC
on 'address into the pointer instead of an address
overlay?

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

Where angles fear to tread!
In my experience, I've never had major incompatibility
problems across compiler implementations. It is rare that
such interfacing code deals with unconstrainted arrays
or polymorphic variant records. Usually just run-of-the-mill
scalars, static records, and constrainted arrays.

> 
> 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!"