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 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e4e9809bdf82397f X-Google-Attributes: gid103376,public From: Robert A Duff Subject: Re: Newbie Access Types Date: 1999/08/27 Message-ID: #1/1 X-Deja-AN: 517817274 Sender: bobduff@world.std.com (Robert A Duff) References: <7pe6tg$dqq$1@dailyplanet.wam.umd.edu> <37c45ac7@eeyore.callnetuk.com> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1999-08-27T00:00:00+00:00 List-Id: "Nick Roberts" 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 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.