Thread: Private static member set to NULL directly?

Originally Posted by dennis.cpp

(Thanks btw for that hint to nullptr - since my textbook uses NULL, I will research about that on this very website.)

You shouldn't use NULL in C++. nullptr is great, but it's new to C++11. With compilers that don't have it, use 0. This can make some more obscure bugs more apparent.

What's wrong with NULL?

nullptr offers some advantages over NULL (eg more type safety). That (contrary to what some zealots claim) is not saying NULL is evil. The choice is one of trade-offs.

NULL is technically a value of zero (or, more pedantically, a value of zero when converted to a pointer is equal to NULL) and can often be treated as an integral value. This causes some problems in C++ with template overloading, because NULL isn't necessarily a pointer. The problems have been exacerbated a bit in C++ because some popular idioms encouraged using a literal value of zero in place of NULL - which basically nudged library vendors to define NULL simply as zero. The main problems come down to type-safety, and nullptr addresses that.

So NULL was problematic in a few edge cases (which were rare in practice), some practices were encouraged (and became more mainstream) that caused it to be problematic more often, and a new keyword is introduced to fix the problem. I personally characterise all that as a self-licking icecream. The result, however, is that you are better off using nullptr than NULL if you are solely targeting compilers that support it. But you will have to keep using NULL (in one form or another) if you care about compatibility of your code (for example, ability to build with compilers that predate 2009 or so).

Actually, I was referring to NULL vs 0 (sorry if that wasn't clear).
I am familiar with the advantages of nullptr.

The original reason for NULL (in C) is that there was no guarantee that a pointer with value zero would not correspond to a valid object (yes, there were examples of hardware where a pointer with all bits set (0xFFFF with 16 bit pointers) was the NULL pointer). The line was blurred later when it was decreed that a value of zero, when converted to a pointer, would be equal to the NULL pointer.

The main remaining advantage of NULL, with modern C/C++ compilers and libraries, is probably about programmer understanding. There is a slight benefit in understanding by a programmer that

Code:

    pvariable = NULL;

initialises a pointer rather than an integer, or that

Code:

    some_function(NULL);

is passing a pointer rather than a value of zero. Some people view such benefits as significant, others do not.

Originally Posted by Elysia

Actually, I was referring to NULL vs 0 (sorry if that wasn't clear).
I am familiar with the advantages of nullptr.

NULL is defined as the literal 0 (usually). In function overloading, 0 matches int better than any pointer. But when a programmer sees NULL they think pointer, and expect the pointer version of an overloaded function to be called. When a literal 0 is written, the error is easier to spot. Here's code illustrating this:

Code:

#include <cstdlib>

int foo(int var){
  return 1;//error
};
int foo(void *var){
  return 0;//expected behavior
}

int main(){
  return foo(NULL); //returns 1
}

Originally Posted by manasij7479

> which basically nudged library vendors to define NULL simply as zero.
How else could NULL be defined ?

In C it's defined as ((void*)0).

It could also be defined as a special type by the compiler, similar to null_ptr, except giving a warning instead of an error when converted implicitly to int.