Re: To Initialise or not

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

In article <318E3A26.3565@lmtas.lmco.com>,
Ken Garlington  <garlingtonke@lmtas.lmco.com> wrote:
>I'm not trying to be initially obscure, but I'm really having trouble seeing
>the power of this knowledge. If you "promise not to read a value," does that
>make it write-only? Unused?

I'm don't understand why you don't understand.  I hesitate to prolong a
debate about a minor issue.  But it's more fun that *some*
discussions...

Let me ask you this:  Suppose Ada had a rule that all integers were
default-initialized to T'First, where T is the subtype of the variable.
Would you be happy with that language?  Would it change the way you
write code?

>However, I think you've missed my point. Let me retry: Do you have a block
>of comments in each compilation unit that says:
>
>-- NOTE: When a declaration using an access type has an explicit initial
>-- value of null, this means that the declared object can be used without
>-- any further initialization.

No, of course not.  It only needs to be stated once.  And there are lots
of other things that need to be stated once, and you need to give the
reader some way of easily finding that place.  I freely admit that if
somebody doesn't understand the coding convention, it won't help them
understand the code.  (It probably won't hurt, either, though.)

>> In other words, pretend that you're coding in a language that's just
>> like Ada, except that there's no default initial value for pointers.
>> Write the code accordingly.  Since this mythical language is a subset of
>> Ada, this is safe.
>
>WHAT?
>
>ATTENTION: SUBSETTING A LANGUAGE DOES NOT, IN ITSELF, MAKE IT SAFE.

ATTENTION: Please understand what I meant by "safe".  I meant, any
coding convention which "pretends" to code in a strict subset of Ada is
a "safe" coding convention, in the sense that the coding convention
cannot produce bugs.

In this example, I meant that it is safe to pretend that Ada doesn't
initialize pointers.  Please re-read what I wrote in this light -- that
is, when I said "THIS is safe", I meant "THIS PRETENSE is a safe
assumption".

This hypothetical not-quite-Ada language was an attempt to answer your
comment saying that it is hard to understand *what* the coding
convention *is*.  It's *not* hard, if you're capable of imagining such a
language.  That's all I meant.  It was not meant as a *justification* of
the coding convention itself (which is based on a minor readability
concern).

It doesn't make sense to answer this hypothetical explanation with,
"But, in Ada 95, pointers *are* initialized to null.  The RM says so."
I *know* that (I *wrote* the darn RM -- well, actually, I think Tucker
wrote that part :-) ), but I'm asking you to imagine an alternative.

By the way, all your examples concerned local variables.  The more
interesting cases are package-body variables, and record components.

>If you believe implicit default values for access types are unsafe, then you
>have to justify that statement. You also have to say why the alternative (adding
>explicit code to replace the implicit code, under certain circumstances) is
>comparatively safer.

No, no, no.  That's not what I meant about "safe".  Of course implicit
null's are just as safe as explicit nulls.

It just seems to me that it's valuable to know whether a given value is
going to be used.  It makes the code more readable, IMHO.  Null is not
special in that regard.

>> Well, I admit, it's not that big a deal.  It's little effort, with
>> little payoff, so we could argue endlessly about the payoff.
>
>We could. However, there is also the KISS principle, which in part says
>"things are only added when they have sufficient justification." In other
>words, if you want to add code, you have to show a clear reason why (particularly
>for safety-critical code). You don't normally say, "It's fairly easy to
>add, so I'll add it, and someone will have to justify taking it out."

In this case, the Ada *language* is what violates the KISS principle.  I
understand the reasons behind it, but still, the rule is that some
variables get a "junk" initial value, and some variables get a
well-defined initial value (by default, of course), which is obviously
more complicated than treating all variables the same.

I claim that the coding convention we're arguing about is actually
*more* KISS, since it treats integers and pointers alike.

>I understand that you want pointers to act like integers. I just don't
>understand _why_, since pointers are conceptually different from integers.

I don't see any way in which integers and pointers are different with
respect to *this* issue (whether or not they should be initialized).  I
understand that they *are* different with respect to this issue in Ada.
But that doesn't mean they are *conceptually* different.

>Here's a different example: Suppose you saw code that looked like:
>
>  X : Integer := Init (Thousands => 1, Hundreds => 4, others => 0)
>                                             -- set X to 1400.
>
>Would this be a preferred approach, since I'm just creating numeric literals
>the way I create array aggregates?

Sorry, but you lost me there.

>> But initializing all access values to null does
>> *not* constitute a "reasonable" initial value, in many cases.
>
>This is certainly true. However, can you identify a case where null _is_ a
>reasonable initial value, but not a reasonable initial _default_ value?

Sure.  I have a hard time imagining a type that is otherwise.

Suppose (stealing from another thread;-)) we have Patients and Doctors.
Each Patient is represented by a record, containing (among other
things), a pointer to its Doctor.  Because of the way this application
works, you can't create a Patient without giving it a Doctor -- i.e.
there is no reasonable default value for the Doctor field, and it must
always be non-null.

However, there's a hash table, implemented as an array of pointers to
Doctors.  I want to initialize all the slots to "null", which means
"this slot is empty now".  Conceptually, the array elements should be
initialized to null, whereas the My_Doctor field of Patient should be
initialized to "Don't touch this!".

I would write ":= (others => null);" on the array, to signify that I
intend to *depend* upon the initial null value, but I would *not* write
":= null" on the My_Doctor component of type Patient, to signify that I
intend to always explicitly initialize it.

>I'm not advocating the use of null as an initial value for all
>accesses, I'm just saying if an acceptable initial value is null, then
>it should be acceptable for the _default_ initial value to be null. At
>least when I read the RM, it doesn't appear to make a clear distinction
>between null as a literal and null as a default value.

Right, your coding convention is just as valid Ada as mine.

Sorry for the perhaps overly strident tone above.  I'm just frustrated
that I can't get across what I'm trying to say.  :-)

Here's a summary:

1. I think this coding convention make code just a little bit more
readable.  It makes a distinction between an initial value that I plan
to read, and an initial value that I don't.

2. I admit that it won't work if the reader doesn't know the convention.

3. The coding convention itself is easy to understand (i.e., it's easy
to understand when to put ":= null" or ":= something-else" on an access
variable or record component or whatever), if you imagine a language
just like Ada, except that it doesn't have the default-null rule.

4. I admit that it has the same problem as comments: if you don't do it
right, the compiler won't tell you so.

- Bob