{"id":98175,"date":"2018-03-07T07:00:00","date_gmt":"2018-03-07T22:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/?p=98175"},"modified":"2019-03-13T00:49:48","modified_gmt":"2019-03-13T07:49:48","slug":"20180307-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20180307-00\/?p=98175","title":{"rendered":"When MSDN says NULL<\/CODE>, is it okay to use nullptr<\/CODE>?"},"content":{"rendered":"

In various places, MSDN will talk about the behavior corresponding to the case where a handle type has the value NULL<\/code>. A customer wanted to know whether it was safe to use nullptr<\/code> in such cases, or whether they have to use NULL<\/code>. <\/p>\n

Although the programming languages used by MSDN for documenting Windows are putatively C and C++, MSDN understands that a lot of people write code for Windows in other languages, and therefore it tries to avoid relying on language subtleties<\/a>. <\/p>\n

Esoteric definitions for the term NULL<\/code> is one of those language subtleties. <\/p>\n

Formally, the C and C++ languages permit the following definitions for the NULL<\/code> macro: <\/p>\n\n\n\n\n
NULL<\/code><\/th>\n0<\/code><\/th>\n(void*)0<\/code><\/th>\nnullptr<\/code><\/th>\n<\/tr>\n
C<\/th>\nallowed<\/td>\nallowed<\/td>\nnot allowed¹<\/td>\n<\/tr>\n
C++<\/th>\nallowed<\/td>\nnot allowed²<\/td>\nallowed<\/td>\n<\/tr>\n<\/table>\n

If NULL<\/code> is defined as (void*)0<\/code> in C or as nullptr<\/code> in C++, then it can be assigned only to a pointer type. And since MSDN cannot control how the C and C++ header files define NULL<\/code>, it needs to work with any definition that is permitted by the corresponding standards. Which means that saying NULL<\/code> implies that the underlying type is a pointer type. <\/p>\n

Therefore, you are welcome to write nullptr<\/code> instead of NULL<\/code> if you’re writing C++ code. You’re also welcome to write anything else that produces a null pointer, such as <\/p>\n

\nHMUMBLE h1 = HMUMBLE();\nHMUMBLE h2 = HMUMBLE{};\nHMUMBLE h3 = HMUMBLE(0);\nHMUMBLE h4 = (HMUMBLE)0;\nHMUMBLE h5 = 3 - 3;\n<\/pre>\n
But most people would probably prefer you to write NULL<\/code> or nullptr<\/code>. <\/p>\n
As noted, MSDN understands that a significant portion of its readership is not fluent in the subtleties of C and C++. When it writes NULL<\/code>, it means the obvious thing: A null pointer. You can translate that into the appropriate construction for the language you are using. For example, for C#, you can use null<\/code>, or if you are operating in raw IntPtr<\/code>s, you can use IntPtr.Zero<\/code>. <\/p>\n
Bonus chatter<\/b>: When MSDN says NULL<\/code>, is it okay to use 0<\/code>? Yes, but you probably don’t want to. Using 0<\/code> as a null pointer constant is permitted by the C and C++ languages for backward compatbility reasons, but it’s not considered modern style. <\/p>\n
Bonus bonus chatter<\/b>: I’m told that the Visual C++ folks occasionally entertain the possibility of changing the definition of NULL<\/code> to nullptr<\/code>, which is permitted by the standard. However, this ends up breaking a lot of code which assumed that NULL<\/code> is an integral constant evaluating to zero. For example: <\/p>\n
\nvoid foo(char* p)\n{\n  char c = NULL; \/\/ would not work if NULL were defined as nullptr\n  *p = NULL;     \/\/ would not work if NULL were defined as nullptr\n  ...\n}\n<\/pre>\n
Although that code is technically already broken, it manages to work if NULL<\/code> is defined as 0<\/code>, and updating the definition in the language header files would break existing (albeit poorly-written) code. <\/p>\n
¹ C does not have the nullptr<\/code> keyword. <\/p>\n
² C++ does not allow NULL<\/code> to be defined as (void*)0<\/code> because C++ does not permit implicit conversion from void*<\/code> to arbitrary T*<\/code>. <\/p>\n
\nint* p = (void*)0; \/\/ allowed in C but not C++\n<\/pre>\n","protected":false},"excerpt":{"rendered":"
One of many equivalent formulations.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-98175","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
One of many equivalent formulations.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/98175","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=98175"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/98175\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=98175"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=98175"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=98175"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}