Re: Setting pointer to null!

On Fri, 3 Apr 2009 16:47:26 +0300, "Alex Blekhman" <tkfx.REMOVE@xxxxxxxxx>
wrote:

"Doug Harrison [MVP]" wrote:
I'm afraid you'll have to explain to me what you're "differing"
with, because it seems to me you've restated what I said.

I disagree with the following statement:

"The best thing is to assign a non-NULL singular value." And
consequently: "In any case, if you "defensively" initialize all
pointers to NULL, you defeat [filling variables with predefined
value] debugging feature!".

Let me explain. I think this debugging fetaure emerged originally
in order to mitigate the uninitialized variables problem. When
developer forgets to initialize a variable and it accidentally
gets zero value at the run time, then this omission may exists
unnoticed for a long time. That's why the debugger cares to fill
uninitialized vars with deliberate garbage, so developer will
notice the omission on teh first attempt to use the variable.

This behavior of the debugger based on the premise that variables
should contain valid data for their lifetime.

Yes, the purpose of this feature is to detect the use of uninitialized
variables, and I thought that was understood. Remember that in C, local
variables could only be declared at the tops of blocks, and it was common
to declare a bunch that would be "initialized" in relatively distant code.
In C++, this is much less of an issue, because you can declare variables
anywhere, and the space over which they exist but really should not exist
is greatly reduced.

In any case, if you always initialize pointers to NULL, including ones for
which NULL is not a valid value at that point in time, you defeat the
debugging feature, because you prevent the compiler from initializing them
with the special pattern. (You also run the risk of introducing new logic
errors, as I've a described a couple of times already.) That's what I've
been saying, and I don't see how it's disputable, so I still don't
understand what you're disagreeing with. It really puzzles me. The only
thing I see that's not perfectly clear you haven't commented on, and that
was my statement about assigning "a non-NULL singular value". Given that I
went on to talk about the compiler doing this (which you clipped and
replaced with your own summary - please stop doing that) I was really
thinking of what the compiler does, and obviously if you were to do it
yourself, you would need to use the same value the compiler uses.

Valid data includes
zero value, which indicates that the variable is empty or
whatever. The same as the class invariant notion in the C++.

But 0 is not a valid value for every variable at every point in time. Just
because some value is in the domain of a type does not imply it's valid for
every variable of that type. It may impart a "predictable" behavior, but it
doesn't mean it's valid, and invalid data can cause incorrect behavior, as
I've already described a couple of times.

Indeed, the following initialization of the `p' pointer seems
redundant:

T* p = 0;
if (...)
{
... not using p
p = ...
}
else
{
... not using p
p = ...
}

However, we all know too well that such code quickly becomes

T* p = 0;

// do something else

if (...)
{
... not using p
p = ...
}
else
{
... not using p
p = ...
}

Where "do something else" part may involve an operation on the `p'
pointer. Once written even the excellent code becomes mediocre as
the time goes. Eventually mediocre code becomes bad code. This
kind of defensive programming will save the future devloper
unnecessary aggravation.

I can't agree that's even remotely common, simply because you don't just
start using a variable without knowing anything about it. Or if you do, you
quickly learn what a mistake it is, and you stop. In C++, it especially
does not happen, because there's no reason to extend the lifetime of p in
that way.

That's why it is often said that initializing a variable is a good
coding practice. It ensures that a variable contains valid data
throughout its lifetime.

The real goal is to minimize the distance between declaration and the
assumption of a valid value. IOW, it's all about lifetime control, because
if a variable does not exist, it doesn't matter what value it would or
wouldn't have. Of course it's best to establish the initial (valid!) value
with initialization; I certainly have not been disputing that.

Unlike languages like C# and Java, C++ does not have "definite assignment".
It does, however, allow you to declare variables near their point of first
use, which mitigates the issue quite a bit for those variables that can't
be initialized when they are declared. Look at the examples here:

http://java.sun.com/docs/books/jls/second_edition/html/defAssign.doc.html

I can't believe you would insist upon initializing every "k" in these
examples. And please note that both C# and Java have "definite assignment",
*not* "required initialization".


--
Doug Harrison
Visual C++ MVP
.

Relevant Pages

  • Re: Replicating results
    ... gradient calculation used in a large optimization routine. ... It will make sure that if you do something like declare a variable called "x1" and use a variable called "xl" the compiler will tell you that xl was undeclared. ... Make sure that you initialize all of your variables, ...
    (comp.lang.fortran)
  • Re: where does the header implentation get inserted
    ... suppose i declare a function in "myLib.h". ... You have to tell the compiler to compile both files, ... "Debugging is twice as hard as writing the code in the first place. ...
    (comp.lang.c)
  • Re: Limited returns
    ... function Factory(w: E) return I'Class is ... when you declare an object of ... then whatever the specific type you initialize it to (in this case, ... A compiler that tries to in-line the call to ...
    (comp.lang.ada)
  • Re: Default value of basic variable type
    ... i remember i read a book talking about when u declare a array variable using ... and all type of numeric variable is initialize to 0, bool type is false, ... The compiler generates an error if you attempt to use the variable before you initialize it (and in many cases, even if you do, if you're not clear enough to suit the compiler:)). ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: abstract sub programs overriding
    ... >>compiler can determine that Object is never referenced before it is ... >>implicit Finalize. ... >>the Initialize is user defined. ... > if that initial value is an aggregate, it has to be built directly in the ...
    (comp.lang.ada)