Re: Logical Value Of A Pointer
On 31 jan, 06:50, Jeff Schwab <j...@schwabcenter.com> wrote:
Andrew Koenig wrote:
I consider
if (p) { /* ... */ }
to be an abbreviation for
if (p != 0) { /* ... */ }
which is an implicit conversion of 0 to a pointer, not of p to bool.
I understand that the standard doesn't describe it that way,
but that's just a matter of descriptive convenience, and
doesn't affect how I personally think about it.
This may go without saying, but you obviously have a very deep
understanding of how C++ syntax can be used to reflect
high-level semantic meaning. I wish that level of
understanding were more widespread.
To a human reader, the != 0 ought to be considered noise,
AFAICS.
It specifies what you are testing for. If a pointer only had
two possible values, it would be noise. Since that's not the
case, it's important information.
The ability to test things other than raw bools is not just
for pointers, either; e.g: while (std::cin >> s) { ... }. I
don't consider p != 0 any better than b != false. And don't
even get me started on NULL. :)
This argument seems to be a perennial favorite on Usenet. It
seems to come down to a division between people who think
generically, and others who think (or at least code)
orthogonally.
The argument goes back long before generic programming. The
argument is between those who believe in static type checking,
and those who are too lazy to type.
Just kidding, of course---but the issue IS type checking.
With regards to "generic" programming, I can understand the need
for some sort of "generic" is valid. The problem is that we
don't have it. Whether you write "if ( p == NULL )", or just
"if (p)", the constraints on p are identical. The difference is
that in the first case, it's clearly apparent what those
constraints are.
The first of these camps, the Generics, believe that syntax
should convey abstract meaning, with low-level details
supplied by context. The second camp, the Orthogonals,
believe that a particular syntax should mean exactly the same
thing in all contexts, and that even (or especially) subtly
things should always look different.
I don't think you've understood the argument. In a well
designed language, pointers aren't boolean values (since they
have more than two values), and can't be used as such. And type
checking is strict, because that reduces the number of errors.
The problem is that the implicit conversion doesn't cover all of
the cases. Even in the case of pointers, we have three cases
which can legally occur: the pointer points to an object, it
points to one behind the end of an array of objects, or it is
null. So which one do you priviledge by the conversion?
I consider myself in the Generic camp. The advantage of this
style is that similar ideas are implemented by similar-looking
code. A single piece of source code can often be reused in
multiple contexts, even if the compiler generates wildly
different object code for each of them. For example, I like
the fact that the following all look the same:
throw_if(!p, "null pointer");
throw_if(!cin, "input error");
throw_if(!divisor, "attempted division by zero");
throw_if( p != 0, "null pointer");
throw_if( cin != 0, "input error");
throw_if( divisor != 0, "attempted division by zero");
They all look the same to me. Even better:
throw_if( isValid( p ), "null pointer");
throw_if( isValid( cin ), "input error");
throw_if( isValid( divisor ), "attempted division by zero");
With isValid defined with an appropriate overload (which would
return false for a pointer one past the end as well---except
that I don't know how to implement that).
Once I understand the pattern, I don't want to have to
optically grep the details of expressions like p == NULL,
!cin.good(), and divisor == 0. They all have the same
high-level meaning, and that's usually what I care about.
The problem is that no one really knows what that high-level
meaning is, since it is radically different for each type.
The apparent down side to this style is that subtle mistakes
can hide in it. It's easy for the reader to see the author's
intent,
The problem is that it's impossible for the reader to see the
author's intent (except from the string literal in your
example---but that's not typically present). It's a recepe for
unreadable code.
but relatively difficult to see the bit-level reality.
However, I would argue that this is the price we pay for
abstraction, and attempts to include context-specific
information in our code without loss of abstraction give only
the illusion of clarity.
The ostensible advantage of something like p != NULL is that p
is clearly a pointer.
No. The advantage is that it isn't "p != 0", and that 0 clearly
isn't a pointer.
The whose system is broken. The problem is that both "p != 0"
and "p != NULL" are lies. The next version of the standard will
fix it somewhat, with nullptr (but for historical reasons, of
course, 0 and NULL must still remain legal).
Or is it? The compiler has no problem with a comparison of
the form std::cin != NULL. In p != NULL, the word NULL seems
to hint that p is a pointer, but that information is neither
relevant to the expression, nor enforceable by the compiler.
G++ warns if you use NULL in a non-pointer context. It could
just as easily generate an error. So this is enforceable by the
compiler.
When it becomes necessary to understand that p is a pointer,
the fact should become evident, as in an expression like
p->size(). Even then, p might be a raw pointer, an iterator,
or some kind of fancy smart pointer. In decent C++ code, IMO,
we shouldn't have to know.
Except that we do, since neither "if (p)" nor "if ( p != NULL )"
nor "if ( p != 0 )" work if p is an iterator.
The real solution here is an appropriate set of overloaded
functions. I use Gabi::begin(), and Gabi::end(), for example;
they work with C style arrays, and are easily made to work with
STL containers. (In other words, if the STL had been designed
for genericity, it would have defined a function begin(
std::vector<> ), and not std:vector<>::begin().)
--
James Kanze