{"id":5019,"date":"2016-11-06T06:14:06","date_gmt":"2016-11-06T06:14:06","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/the-null-pointer-constant-nullptr\/"},"modified":"2023-06-26T12:37:10","modified_gmt":"2023-06-26T12:37:10","slug":"the-null-pointer-constant-nullptr","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/the-null-pointer-constant-nullptr\/","title":{"rendered":"The Null Pointer Constant nullptr"},"content":{"rendered":"

The new null pointer nullptr cleans up in C++ with the ambiguity of 0 and the macro NULL.<\/p>\n

<\/p>\n

The number 0<\/h2>\n

The issue with the literal 0 is that it can be the null pointer (void*)0<\/span> or the number 0. This is up to the context. I admit we are used to this oddity. But only almost.<\/p>\n

Therefore, the small program with the number 0 should be confusing.<\/p>\n

<\/p>\n

\n\n\n\n
\n
 1\r\n 2\r\n 3\r\n 4\r\n 5\r\n 6\r\n 7\r\n 8\r\n 9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21<\/pre>\n<\/td>\n
\n
\/\/ null.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <typeinfo><\/span>\r\n\r\nint<\/span> main(){\r\n\r\n  std::cout << std::endl;\r\n\r\n  int<\/span> a= 0;\r\n  int<\/span>* b= 0;\r\n  auto<\/span> c= 0;\r\n  std::cout << typeid(c).name() << std::endl;<\/span>\r\n\r\n  auto<\/span> res= a+b+c;\r\n  std::cout << \"res: \"<\/span> << res << std::endl;\r\n  std::cout << typeid(res).name() << std::endl;<\/span>\r\n  \r\n  std::cout << std::endl;\r\n\r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
 <\/p>\n
The question is: What are the data type of variable c<\/span> in line 12 and variable res<\/span> in line 15?<\/p>\n
\"null\"<\/p>\n
The variable c<\/span> is of type int<\/span>, and the variable res<\/span> is of type pointer to int: int*.<\/span> Pretty simple, right? The expression a+b+c i<\/span>n line 15 is a pointer arithmetic.<\/p>\n<\/p>\n
The macro NULL<\/h2>\n
The issue with the null pointer NULL is that it implicitly converts to int.<\/span> Not so nice.<\/p>\n
According to <\/span>en.cppreference.com <\/a>the macro NULL is an implementation-defined null pointer constant. A possible implementation: <\/p>\n
<\/p>\n
\n
#define NULL 0<\/span>\r\n\/\/since C++11<\/span>\r\n#define NULL nullptr<\/span>\r\n<\/pre>\n<\/div>\n
 <\/p>\n
But that will not apply to my platform. Null seems to be of the type long int. <\/span>I will refer to this point later. The usage of the macro NULL raises some questions.<\/p>\n
 <\/p>\n
<\/p>\n
\n\n\n\n
\n
 1\r\n 2\r\n 3\r\n 4\r\n 5\r\n 6\r\n 7\r\n 8\r\n 9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\n26\r\n27\r\n28\r\n29\r\n30<\/pre>\n<\/td>\n
\n
\/\/ nullMacro.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <typeinfo><\/span>\r\n\r\nstd::string overloadTest(int<\/span>){\r\n  return<\/span> \"int\"<\/span>;\r\n}\r\n\r\nstd::string overloadTest(long<\/span> int<\/span>){\r\n  return<\/span> \"long int\"<\/span>;\r\n}\r\n\r\n\r\nint<\/span> main(){\r\n\r\n  std::cout << std::endl;\r\n  \r\n  int<\/span> a= NULL;\r\n  int<\/span>* b= NULL;\r\n  auto<\/span> c= NULL;\r\n  \/\/ std::cout << typeid(c).name() << std::endl;<\/span>\r\n  \/\/ std::cout << typeid(NULL).name() << std::endl;<\/span>\r\n  \r\n  \r\n  std::cout << \"overloadTest(NULL)= \" << overloadTest(NULL) << std::endl;<\/span><\/span>\r\n  \r\n  std::cout << std::endl;\r\n\r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
 <\/p>\n
The compiler complains about the implicit conversion to int<\/span> in line 19. That’s ok. But the warning in line 21 is confusing. The compiler automatically deduces the type of the variable c<\/span> to long int<\/span>. At the same time, it complains that the expression NULL<\/span> must be converted. My observation is following the call overloadTest(NULL)<\/span> in line 26. The compiler uses the version for the type long int<\/span> (line 10). If the implementation uses NULL<\/span> of type int,<\/span> the compiler will choose overloadTest<\/span> for the parameter type int<\/span> (line 6). That is fine according to the C++ standard.<\/p>\n
\"nullMacro\"<\/p>\n
Now I want to know the current null pointer constant NULL type.<\/span> Therefore, I comment on lines 22 and 23 of the program.<\/p>\n
\"nullMacroType\"<\/p>\n
NULL seems for the compiler on one hand of type long int<\/span> and the other hand a constant pointer. This behavior shows the compilation of the program nullMacro.cpp.<\/span><\/p>\n
I learned my lesson. Don’t use the macro NULL.<\/p>\n
But we have our rescue with the new null pointer constant nullptr.<\/span><\/p>\n
The null pointer constant nullptr<\/h2>\n
The new null pointer nullptr<\/span> cleans up in C++ with the ambiguity of 0 and the macro NULL. nullptr is and remains of type std::nullptr_t.<\/span><\/p>\n
You can assign arbitrary pointers to a nullptr. <\/span>The pointer becomes a null pointer and points to no data. You can not dereference a nullptr.<\/span> The pointer of this type can on the one hand compared with all pointers and can, on the other hand, converted to all pointers. This also holds true for pointers to class members. But you can not compare and convert a nullptr<\/span> to an integral type. There is one exception to this rule. You can implicitly compare and convert a bool value with a nullptr.<\/span> Therefore, you can use a nullptr<\/span> in a logical expression.<\/p>\n
\n\n\n\n
\n
 1\r\n 2\r\n 3\r\n 4\r\n 5\r\n 6\r\n 7\r\n 8\r\n 9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\n26\r\n27\r\n28\r\n29\r\n30\r\n31\r\n32<\/pre>\n<\/td>\n
\n
\/\/ nullptr.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <string><\/span>\r\n\r\nstd::string overloadTest(char<\/span>*){\r\n  return<\/span> \"char*\"<\/span>;\r\n}\r\n\r\nstd::string overloadTest(long<\/span> int<\/span>){\r\n  return<\/span> \"long int\"<\/span>;\r\n}\r\n\r\nint<\/span> main(){\r\n\r\n  std::cout << std::endl;\r\n\r\n  long<\/span> int<\/span>* pi = nullptr;       \r\n  \/\/ long int i= nullptr;       \/\/ ERROR<\/span>\r\n  auto<\/span> nullp= nullptr;          \/\/ type std::nullptr_t<\/span>\r\n  \r\n  bool<\/span> b = nullptr;           \r\n  std::cout << std::boolalpha << \"b: \"<\/span>  << b << std::endl;\r\n  auto<\/span> val= 5;\r\n  if<\/span> ( nullptr < &val ){ std::cout << \"nullptr < &val\"<\/span> << std::endl; }  \r\n\r\n  \/\/ calls char*<\/span>\r\n  std::cout << \"overloadTest(nullptr)= \"<\/span> <<  overloadTest(nullptr)<< std::endl;\r\n\r\n  std::cout << std::endl;\r\n\r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
  <\/p>\n
The nullptr<\/span> can be used to initialize a pointer of type long int<\/span> (line 18). But it can not be used to initialize a variable of type long int<\/span> (line 18). The automatic type deduction in line 20 is quite interesting. nullptr<\/span> becomes a value of type std::nullptr_t.<\/span> The null pointer constant behaves like a boolean value initialized with false.<\/span> You can observe that in lines 22 – 25. If the nullptr<\/span> has to decide between a long int<\/span> and a pointer, it will decide on a pointer (line 28).<\/p>\n
Here is the output of the program.<\/p>\n
 <\/p>\n
\"nullptr\" <\/p>\n
The simple rule is: Use nullptr<\/span> instead of 0<\/span> or NULL<\/span>.<\/strong> Still not convinced? Here is my last and strongest point.<\/p>\n
Generic code<\/h2>\n
The literal 0<\/span> and NULL<\/span> show in generic code their true nature. Thanks to template argument deduction both literals are integral types in the function template. There is no hint that both literals were null pointer constants.<\/p>\n
 <\/p>\n
<\/p>\n
\n\n\n\n
\n
 1\r\n 2\r\n 3\r\n 4\r\n 5\r\n 6\r\n 7\r\n 8\r\n 9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19<\/pre>\n<\/td>\n
\n
\/\/ generic.cpp<\/span>\r\n\r\n#include <cstddef><\/span>\r\n#include <iostream><\/span>\r\n \r\ntemplate<\/span><class<\/span> P<\/span> >\r\nvoid<\/span> functionTemplate(P p){\r\n  int<\/span>* a= p;\r\n}\r\n \r\nint<\/span> main(){\r\n  int<\/span>* a= 0;           \r\n  int<\/span>* b= NULL;              \r\n  int<\/span>* c= nullptr;\r\n \r\n  functionTemplate(0);   \r\n  functionTemplate(NULL);\r\n  functionTemplate(nullptr);  \r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
 <\/p>\n
You can use 0<\/span> and NULL<\/span> to initialize the int pointer in lines 12 and 13. But if you use the values 0<\/span> and NULL<\/span> as function template arguments, the compiler will loudly complain. The compiler deduces 0<\/span> in the function template to type int and<\/span> NULL<\/span> to the type long int<\/span>. But these observations will not hold for the nullptr. nullptr<\/span> is in line 12 of type std::nullptr_t<\/span> and nullptr<\/span> is in line 8 of type std::nullptr_t.<\/span><\/p>\n
 \"generic\"<\/p>\n
What’s next?<\/h2>\n
In my last post, I presented many features in C++ to make your code safer. Which one? Have a look at high safety requirements <\/a>on the overview page. The key idea of all these features is to use the compiler’s smartness. Therefore, we follow one of the critical principles of C++: Compile time errors are better than run time errors.<\/strong><\/p>\n
With the next posts, I switch the focus. My focus will change from the C++ features that are important for safety-critical features to the features that are important for performance reasons. I will have in the next post<\/a> <\/span>a deeper look into inline.<\/span> Thanks to the keyword inline,<\/span> the compiler can replace the function call with its function invocation. Therefore, the expensive call of the function becomes superfluous.<\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p><\/p>\n","protected":false},"excerpt":{"rendered":"
The new null pointer nullptr cleans up in C++ with the ambiguity of 0 and the macro NULL.<\/p>\n","protected":false},"author":21,"featured_media":5014,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[364],"tags":[514,496],"class_list":["post-5019","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-embedded","tag-nullptr","tag-pointers"],"_links":{"self":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5019","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/comments?post=5019"}],"version-history":[{"count":1,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5019\/revisions"}],"predecessor-version":[{"id":6929,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5019\/revisions\/6929"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media\/5014"}],"wp:attachment":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media?parent=5019"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/categories?post=5019"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/tags?post=5019"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}