Re: To Initialise or not

[bobduff@world.std.com (Robert A Duff)]

In article <4matk0$4k@usafa2.usafa.af.mil>,
Chris Warack <sys mgr> <sys mgr> wrote:
>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).

Well, that's not really a "clarification".  Heap data is variables, too.

In Ada, "object" means "variable or constant".  It has nothing to do
with whether the thing is stack-allocated or heap-allocated.  (Sorry for
being pedantic, after ranting about "Ada" vs. "ADA" pedants.  ;-) )

Presumably, any rule that prevents reads of uninitialized variables
would prevent uninitialized constants from existing at all (so no checks
would be required on reading a constant), because all constants are
initialized with some expression, and if *that* expression is a read of
an uninit var, it would raise an exception.

But a method that works for declared variables ought to work for heap
variables, too.  It seems silly to have a run-time method that works
only for stack variables, since that's the case that can *often* be
detected at compile time.

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

As I said elsewhere, you don't usually need an entire extra bit for
this.  "type T is range 1..1_000_000;" fits in 32 bits.  If you add an
extra value for this sort of checking, it *still* fits in 32 bits.

Not making it part of the object is possible, but complicated, and
probably less efficient.

>...  You could think of 
>this check as something like the elaboration check.

I.e., grossly inefficient and disgusting?  ;-)

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

I'm not sure what you're saying here.  Note that Ada defines a read of
an uninit *scalar* variable to be wrong, but not a read of an uninit
composite.  And that's good.  Consider a record containing an array of
integers, plus the index of the last-used element.  It is (and should
be) perfectly OK to pass that thing as a parameter, or assign "X:=Y",
even though the integers past the last-used one are uninitialized.

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

The first could, too.  A vendor is allowed to define
implementation-defined check names that can be used in pragma Suppress.
So, a vendor could check (scalar) variables for uninitialized access,
and raise an exception in that case, and allow pragma Suppress to turn
it off.

(However, a vendor has to support packing -- e.g. a packed array of
Boolean has to take 1 bit per component.)

- Bob