Re: Newbie Access Types

[Robert A Duff <bobduff@world.std.com>]

"Nick Roberts" <nickroberts@callnetuk.com> writes:

> However, it also seems to me that it could be quite cogently argued that
> such an initialisation is folly, in that there is no reason why the
> subprogram failing to set the value of the parameter (to something logically
> sensible in the prevailing context) should not cause the program to come
> crashing disastrously down anyway. (And the language allows worse things to
> happen anyway, such as when an abort divides an operation to do with access
> values.)

The fact that an obscure and rarely-used feature like abort is dangerous
(and we don't know how to design the language otherwise) is not a good
reason to make an every-day run-of-the-mill feature like parameter
passing also dangerous.

> I would not, myself, subscribe to such an argument,

Good.  :-)

>... since I (and, I imagine,
> others) would hold that, in practice, there will be many situations where
> such an initialisation will save a problem turning into a crisis.
> 
> I should imagine that the initialisation could be eliminated by an optimiser
> under certain circumstances, but (as I'm sure Robert Dewar would be quick to
> point out) it may well be that this optimisation would never be worthwhile
> in practice (too complicated for the small benefit).

The initialization of the parameter is done at the call site, whereas
the information needed to eliminate it is in the called procedure.
So doing such an optimization requires the compiler to know about
both places at once, which makes it harder.

> -------------------------------------
> Nick Roberts
> http://www.adapower.com/lab/adaos
> -------------------------------------
> 
> Ronald Ayoub <rayoub@wam.umd.edu> wrote in message
> news:7pe6tg$dqq$1@dailyplanet.wam.umd.edu...
> | I have read that an access type parameter is always copied in even when
> | the parameter is an out parameter and that this is so that the access type
> | is not undefined which can cause problem. Could someone please elaborate
> | on this? It is my thought that access types are initialized to null when
> | not explicitly initialized so that an uncopied access type going into a
> | function will only result in the formal parameter being initialized to
> null.
> | Maybe I'm being picky but I like to learn things thoroughly.

It was a design goal of Ada 83 that access values could never be
undefined (except via low-level chapter-13-ish features, and things like
abort).  Therefore, a parameter has to be initialized to *something*.
For an 'out' parameter, null could work, or the value of the actual
could work.

That Ada 83 design goal always seemed silly to me, because
"Some_Array(Some_Uninitialized_Integer) := 99;" can do just
as much damage as "Some_Uninitialized_Pointer.all.X := 99;".
If I were designing the language, there would be run-time checks
for uninitialized vars.  People who gripe about slowness would
be told to use pragma Suppress.

Note that the rules for uninit integers and whatnot changed in Ada 95.

Also, in Ada 95, we have anonymous access types (for parameters and
discriminants), and they have no null value, so it's not possible to
initialize such parameters to null.

- Bob

-- 
Change robert to bob to get my real email address.  Sorry.