Re: To Initialise or not

[Ken Garlington <garlingtonke@lmtas.lmco.com>]

Robert A Duff wrote:
> 
> No, sorry, I just meant the "if ... = null" as an *example*.  The
> general point is: If I explicitly initialize, then I plan to read that
> value, at least in some cases.  If I don't, then I promise I won't read
> that value.

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?

> 
> >3. How do you relay this convention to the reader, so that they understand
> >   what it means?
> 
> The coding convention is easy to understand.  Do you know when it's
> necessary to explicitly initialize an Integer variable?

Sure - when the code will fail to function correctly if I don't. However,
that's not the case here, since the code will function exactly the same
whether null is implicit or explicit.

> The coding
> convention is to explicitly initialize pointer variables in exactly the
> same cases -- namely, when the code plans to read that value, before
> some other assingment statment.

However, there's a difference. For example, consider this case with Integer:

declare
  Q : Integer;
begin
  Do_Something;

  if Q = 7 then
   ...
  end if;

end;

This code is erroneous. I know this because I don't have Q initialized prior
to the test. I can make it work by giving an initial value to
Q, either at declaration or just before the "if". On the other hand:

declare
  type A_Type is access ...
  A: A_Type;
begin

  Do_Something;

  if A = null then
    ...
  end if;

end;
   
This code is just fine. I don't look at this code, and say, "But wait a
minute! He didn't set A to null before he read A!" I know that A is null
at this point. It's a little odd to have a test that will always pass,
but setting A to null explicitly will not make the test more understandable
to me.

Moving on:

declare
  type A_Type is access ...
  A: A_Type;
  B: A_Type := new ...
begin

  Do_Something;

  if A = B then
    ...
  end if;

end;

This code is also odd, since the test will always fail. Will setting A
to null make it less odd?

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.

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

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.

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

> I agree.  You don't initialize integers to show they're integers, and you
> don't initialize them because of some specific comparison with zero.
> You initialize them if and only if the initial value can be read.
> I'm just advocating doing the same thing for pointers.

I understand that you want pointers to act like integers. I just don't
understand _why_, since pointers are conceptually different from integers.
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?

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

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.

-- 
LMTAS - "Our Brand Means Quality"