>whereas the latter might indicate that something is simply integrally zero
>though it's perfectly clear what (p!=0) means when p is a pointer, of course
Am I the only one that reads this as you contradicting your own argument?
>whereas the latter might indicate that something is simply integrally zero
>though it's perfectly clear what (p!=0) means when p is a pointer, of course
Am I the only one that reads this as you contradicting your own argument?
My best code is written with the delete key.
I understood him as describing an obvious, well-known exception to its normal uses. Not a contradiction.
Salem: the casting rules appear to be correct since at least 1988, though many books included warnings about the old casting behavior of 'K&R' C. I looked for my old textbook but could not find it. It's only fifteen years out of date, you would think I would have such things on hand.
>I understood him as describing an obvious, well-known exception to its normal uses.
I understood him as well.
>Not a contradiction.
I disagree. When p is a pointer then
compares the pointer to null. When p is an integer then the above compares the integer to 0. I see no difference between that andCode:if ( p != 0 )
where if p is a pointer it is assigned the value of a null pointer and if p is an integer it is assigned the integral value 0. My point about contradiction is that Sebastiani stated that 0 may indicate the integer 0 while NULL is guaranteed to be a null pointer, but then immediately after that when p is a pointer it's perfectly clear a null pointer is intended. As such, there is no ambiguity as suggested by the first statement, thereby contradicting it. Does this make sense? Or am I being overly pedantic?Code:p = 0;
My best code is written with the delete key.
I understood Sebastiani as stating the uses based on what looks more proper, not based on anything technical. And that using p != 0 when p is a pointer is something that happens to be used so often, that everyone knows what it means. I know where you are coming from, and I do not agree with using p != 0 for pointer comparison, myself. I have always though that NULL is equal to 0, regardless of a type cast or not, or what compiler is being used. But, I have never written code that depends on this, as I never use NULL to set or compare a variable that is not a pointer. I do not even like to use if statments without the explicit "p == NULL" or "p != NULL" within them, when comparing a pointer to NULL.
>> Am I the only one that reads this as you contradicting your own argument?
Actually the logic of my statement did come out bad. All I was trying to say was that NULL is used with pointers to add visiblity and clarity. Use with integral results doesn't make sense naturally, so is avoided.
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
I head that NULL is something that points to 0...and therfore in a way also is 0.
Its all a matter of willpower
I´m getting confused with all these informations. When I use 0 to compare a pointer, will the compiler convert it to the right NULL specification, if the NULL is not 0?
Nothing more to tell about me...
Happy day =)
> I head that NULL is something that points to 0...and therfore in a way also is 0.
Go read the refresher course I posted - NULL doesn't point to anything, zero or otherwise.
> When I use 0 to compare a pointer, will the compiler convert it to the right NULL specification
Yes
NULL, whether its
#define NULL 0
#define NULL (void*)0
does squat for the compiler, and merely serves to enforce the idea that a pointer comparison is taking place in the mind of the reader.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
