Re: To Initialise or not

[cwarack@cs.usafa.af.mil (Chris Warack <sys mgr>)]

In article <3188AF51.1F1A7590@escmail.orl.mmc.com>, "Theodore E. Dennison" <dennison@escmail.orl.mmc.com> writes:
|> Robert A Duff wrote:
|> > 
|> > In article <318792E8.28CC1042@escmail.orl.mmc.com>,
|> > Theodore E. Dennison <dennison@escmail.orl.mmc.com> 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.