On 06/09/12 09:50, Harald wrote:
...
so IMHO - NULL not being a zero value is pre-ANSI C (btw. that's my generation) - if(pointer) is C++ and C standard compliant (conversion to bool) - NULL is not sufficient in many other cases (like overloaded function selection) and in no way better than 0 here we have to use (CLASS*)0 instead, with the correct CLASS - in C++ NULL is usually explicitly defined as 0 whereas in C (#ifndef __cplusplus) it is defined as (void*)0, please look in mixed headers _______________________________________________
Ok, after researching the subject I have to admit that you are basically right though the matter is not as easy as you or I thought. It's another good example that shows that even plain C is not an easy/simple language as soon as you look into details. The machine's null-pointer *address* is in fact undefined. There are machines where the 0-address is valid or another bit-pattern is used for some reason... In C(++), the null-pointer constant is always zero and the NULL macro and can be defined in different ways but only regarding the type it yields (void *, int, long) whereas it must always be zero-valued. The definition of NULL as ((void*)0) is only allowed and common in plain C. The compiler must opaquely translate C null-pointers to the machine's internal null-pointer and vice versa. According to this answer in the comp.lang.c FAQ, the null-pointer should always effectively evaluate as false in boolean expressions regardless of its actual value: http://c-faq.com/null/ptrtest.html In plain C at least, this has nothing to do with the semantics of casting to the boolean type which does not even exist (prior to C99). AFAIK the type of boolean expressions is still int even in C99. Because of the confusion surrounding null-pointers in C(++), I would still consider it good coding style to explicitly compare with NULL, but who cares... My own confusion stemmed from the fact that I once argued with a teacher who told me he used a Windows C compiler where NULL was defined differently and the null-pointer test did not work as expected. Apparently the compiler he was using is broken or the NULL macro was redefined somewhere else - a condition which can indeed result in such unexpected behaviours (and much confusion) as you can easily try out yourself. Best regards, Robin