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,c1131ea1fcd630a X-Google-Attributes: gid103376,public From: cwarack@cs.usafa.af.mil (Chris Warack ) Subject: Re: To Initialise or not Date: 1996/05/02 Message-ID: <4matk0$4k@usafa2.usafa.af.mil>#1/1 X-Deja-AN: 152628049 distribution: usafa sender: cwarack@kirk.usafa.af.mil (Chris Warack ) references: <318508FE.204B@sanders.lockheed.com> <318792E8.28CC1042@escmail.orl.mmc.com> <3188AF51.1F1A7590@escmail.orl.mmc.com> organization: USAFA Dept of Computer Science newsgroups: comp.lang.ada Date: 1996-05-02T00:00:00+00:00 List-Id: In article <3188AF51.1F1A7590@escmail.orl.mmc.com>, "Theodore E. Dennison" writes: |> Robert A Duff wrote: |> > |> > In article <318792E8.28CC1042@escmail.orl.mmc.com>, |> > Theodore E. Dennison wrote: |> > >Yes, but I don't think any compiler COULD easily help enforce this (It |> > >sounds a lot like the halting problem to me). That is what code |> > >walkthroughs are for. |> > |> > A compiler can *easily* detect uninitialized variables at run time. |> > Yes, it's nicer to know about it at compile time, when possible, but as |> |> Well, no. A compiler can't detect a thing at run-time. The compiler is |> not even running then. It is happily asleep on the disk, dreaming |> compiler dreams. |> |> I do see what you are getting at, but I don't think adding a "dirty |> bit" to every varaible is a serious consideration. (At least, the |> systems programmer in me HOPES it isn't). Unfortunately, that's about the only option possible. However, it's not as gloomy as it might seem. First, a clarification -- need a dirty bit for each "object" not each variable (i.e., it has to handle "heap" data as well as "stack" data). Second, the bit doesn't have to be part of the object (although adding such a flag as part of an ADT or class definition is a simple way for the user to gain this feature). You could think of this check as something like the elaboration check. The advantage of having this in the language is that the compiler may be able to optimise these checks away whereas if the user codes them, this becomes difficult. The reason is that the compiler could do the checks as part of "calling" an operation and therefore determine from the calling context whether the object was initialized or not. The user code would be in the implementation of the operation and could not benefit from the calling context. The extra time these checks would add is probably not worth it in many (most) arenas. But, if they existed, a pragma Supress(Initializion_Checks) could turn them off. I suppose that having them off by default may be best and a pragma Initialization_Checks would turn them on. Of course, this second approach could be implementated right now as vendor-dependent pragma... As some have stated, it could be simple to implement this for run-time check of all variables (in fact, the compiler can catch a lot of these). However, I can think of two trickier cases... 1) tracking dynamically allocated objects, and 2) completely handling component-wise initializations of arrays and records. Other people have mentioned interfacing to other languages, but I'm not sure that would be so difficult to handle (by nothing else than ignoring it, perhaps) Case 1 is tied into whatever book-keeping scheme you use. With flags attached to an object it is not hard, but other methods might be tricky. Case 2 is not a problem if you accept the initialization of any component as the initialization of the object. If you want complete initialization to be checked, this becomes much more complicated -- and, of course, that's what you really want... Could be an interesting master's project here... Add initialization_checks to GNAT such that it is transparent (I can turn initialization_checks off and rep clauses and such are not affected -- only the exception behavior would change). -- Christopher A. Warack, Capt, USAF cwarack@cs.usafa.af.mil (719) 472-2401 Computer Science Department, US Air Force Academy This content in no way reflects the opinions, standards, or policy of the USAF Academy, or the US government.