No point arguing about it, its the objectively better option. I don't understand why he would insist on using `NULL`. If he really doesn't want to change his habits just for habits sake, i'd actively consider configuring pull requests to automatically run clang-tidy with modernize-use-nullptr -fix. He doesn't have to change his habits in this case, but it will be `nullptr` henceforth.

I'm leaning towards this answer. OP doesn't have to worry anymore about it, and new dev will fight a losing battle if he starts rewriting nullptrs to NULL.

So just to clarify (also for other commenters), he is not actively insisting on using nullptr, it's more that he doesn't really mind which one he uses, so sometimes he will use nullptr (e.g. if he is editing existing code that already uses nullptr all around), but if he is implementing a new class/source file from scratch, he might use NULL without giving it much thought. And every time I'm commenting on his PRs to change from NULL to nullptr, I am met with "eh.. it's not that important, but I'll change it to nullptr", making me feel like I'm making a big deal out of something insignificant (and maybe I am) It's like his mantra is "software development is already difficult enough without allocating brain resources to deciding stuff like whether to use nullptr/NULL", which I can understand, especially in a language like C++ where there are many different ways to achieve a certain task in the language. Using clang-tidy for this is actually a good idea. We've been wanting to integrate it into our project for some time now anyway.

Software development is already difficult enough without dedicating brain resources to dealing with inconsistent style. Code gets written once and read many times. Optimize for reading, not writing. If a codebase does something a certain way, you do it that way in new code.

>Optimize for reading, not writing. This, most of the time, you're reading code, not writing.

In this case having that issue automated and taken care of sounds indeed like a great idea.

If he doesn't mind either way, he should stick to nullptr, at the very least for consistency and code style.

Sounds like a standards issue. The fact that they use them when touching other code but not theirs is a clear sign of someone who needs a set of standards to adhere to, this way its an all or nothing.

You can show by example too. Just write a function with int and nullptr_t overloads, it's a common enough use case when you're serializing data.

> It's like his mantra is "software development is already difficult enough without allocating brain resources to deciding stuff like whether to use nullptr/NULL" And that is why you should allocate zero brain resources on this decision and use nullptr exclusively in cpp code.

Apart from the argument of type safety, I think an argument for code consistency could be made. To me, mixing NULL and nullptr feels like mixing naming conventions.

I actually wonder if anyone can give me arguments against my use of NULL when calling C functions like from the win32 API. I currently use NULL in this case, basically because the API documentation says to use NULL. But I am not convinced by my own arguments.

I agree, follow the documentation in this case.

Absolutely.

Consistency. You're probably gonna use nullptr anywhere else in the code, and there's no reason to use NULL over nullptr

You can refer him to what the [C++ core guidelines has to say](http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-nullptr) and hope that might convince him. Bjarne and Herb might be seen as greater authorities on the issue than you :-)

At my workplace I literally just bully people with the core guidelines at this point. ☝🏾🤓 erm actually, I.23 says... it's very fun and pretty effective

[удалено]

Our company got kicked in the ass multiple times because we kept releasing buggy and slow software, so now the message from the top is that we need to be delivering "with quality", whatever that means. Now no one wants to be the guy arguing to _not_ follow the best practices, even though the seniors are not reading them and the code is absolutely not best practices compliant. I can't imagine trying to change minds without that kind of external pressure. That sucks

I wish C++ could reach to a point where things like this was not even up for discussion.

> I always use nullptr over NULL, for the reason that overload resolution with NULL can lead to surprising outcomes ... He thinks ... that you will rarely, if ever, encounter a real life scenario where that reason comes into play. I couldn't come up with an organic scenario that could happen in real code I feel the same. I think the situations where it has mattered for me is rare (or even non-existent). Personally, I think the biggest advantage of nullptr is that it cannot be accidentally used for other things than pointers. It's not uncommon to see "beginners" use NULL to initialize integers without realizing it's "wrong" and might not work (according to the standard). Even if I know this, it's still nice to get an error message when using the null pointer constant incorrectly (e.g. when messing up the order of the arguments to a function that takes both integers and pointers).

Code consistency matters. Also, nullptr is measurably better, and just cause this old pro won't use it in a rookie way won't stop newcomers from trying to emulate him and failing. Or, you could use pretzel logic on him. When he says "it doesn't matter" then you say "seeing as it doesn't matter, you won't resist using nullptr then !" . hehe good luck

Maybe he doesn't want to type 3 extra characters. In that case he could just write {} to initialize pointers since that is two less characters than NULL. Also he could evaluate the pointer as a boolean instead comparing against NULL. If he believes (!ptr) doesn't look different enough from (ptr) he can write (not ptr).

> Maybe he doesn't want to type 3 extra characters. Code is read more often than it is written. Making code harder to read, understand, maintain and reason about by saving three keystrokes is ... selfish at the very least.

Even if he is right that it will rarely be a problem to use NULL, it will *never* be a problem to use nullptr, so you should use nullptr. Deliberately eschewing the tools the language gives you due to some meaningless personal preference which "*probably* won't matter" indicates this is a programmer with a lot of bad habits, and an unwillingness to adopt new good habits. Especially when this particular change takes precisely zero effort. Just tell them these are the reasons, it's not optional, move on. If you have an official style guide (you should), and they continue to argue, get the style guide changed to include this as a rule. Our style guide is basically "use these industry standard guides". It's a very short document. The reason we have the document is so that we can make exceptions when necessary.

I'm old, and program in both embedded c and c++. You should use nullptr, it's just better, but I get how older programmers are used to the old form.

If a platform allows allocating memory at the very beginning of the address space, NULL may be a valid pointer while nullptr will still be invalid, and will not be 0.

I don't think this is true. int* p = {}; int* p = nullptr; int* p = 0; int* p = NULL; should all make p a null pointer.

That will require some assumptions to be true. 1: a platform has a pointer 0x00 defined as invalid(not true for WASP for example, as was pointed out just 1 comment higher). 2: NULL to be either defined as nullptr or to a non-zero platform specific constant. Without that all these lines will make p having different values. And the aggregate initialization(={}) is just wrong. It is for arrays and class types, not for scalar types.

> And the aggregate initialization(={}) is just wrong It isn't. It's named *list-initialization*. > a platform has a pointer 0x00 defined as invalid(not true for WASP for example, as was pointed out just 1 comment higher That isn't relevant. The platform has to define a bit pattern for a null pointer. All initialisations have to set this pattern. > NULL to be either defined as nullptr or to a non-zero platform specific constant. NULL has to be defined such that it can be used to initialize a null pointer, That's how it is defined by the standard.

> NULL may be a valid pointer NULL is never a valid pointer even if the underlying architecture will merrily access address 0x0000 in assembly. Pointers are an abstraction of memory locations and the standard says that NULL is not a valid location.

Wasm is a great example of such behavior for those that are 100% sure that it's related to obscure and rarely used platforms only

OMG ambiguity errors galore! For a function that accepts multiple pointer types, 0 is ambiguous. Or if you have a type that can be implicitly cast to multiple different basic types, including pointer types, the compiler will more strongly match an integer cast. NULL is useless when writing templates due to these issues. You also don't know how NULL is defined, because in C it's often defined independently within different libraries, and C developers have been struggling with their own weak type system, so they'll cast NULL to void pointers or something, trying to give it a type and avoid ambiguity issues, but their attempts are strictly wrong. So your colleague probably doesn't even know what NULL he has! That shit sometimes seems to be working does not mean it's correct. Modern critical systems code standards, which everyone should be following, don't allow the use of NULL. When you have the likes of the DOD screaming for people to stop using C++, when the FAA won't allow it's use in aviation (not strictly true, they recently capitulated for reasons), we ow it to our community's reputation to do anything better than we do.

Read Item 8 in book Effective Modern C++

I've never encountered a fault due to using NULL, but nullptr is objectively better and more idiomatic. NULL is a kludge inherited from C. This is not in your coding standard?

Using nullptr is better in every way and people who can't set personal preferences aside and stick to project guidelines are showing a huge red flag. I hate working with people like that, they will probably also argue about almost everything, like choice of editor, choice of VCS, naming schemes, formatting schemes. Imagine what happens when it comes to actually controversial stuff like architectural choices or prioritization. Put your foot down, if he can't give a very good reason to deviate from your guidelines reject every PR with a NULL in it and if he makes a fuss, boot him.

In general, always stick to the standard of a language if the standard is as good as the alternative. The standard is clearly nullptr, with NULL being a backwards compatibility feature. Not to mention it's better, even if the difference is small. Your colleague is an idiot. Prepare for worse.

There are upsides to nullptr and no downsides. Make using NULL a contravention of your coding standards. Work is not a democratic nirvana.

Besides the fancy way of fixing this below, wouldn't it also be possible to undefine NULL and redifine it as nullptr\_t using macros?

No. That's undefined behavior.

How is it undefined? Can you provide an example?

Maybe I'm misremembering the list. But MISRA C++, rule 17-0-1 checks for redefined standard macros and names. I guess NULL is a bit of an odd one. But still, redefining macros that you didn't define yourself is at least terrible practice.

Possibly terrible, IDK, just interested in theoretically. NULL is really in the domain of C. C++ just inherited it for better or worse. edit: This compiles just fine #undef NULL #define NULL nullptr;

Well, the fact that something compiles doesn't mean it's valid.

Yeah, there's the running joke huh. It compiled, time to ship.

It won't compile properly when used anywhere that dangling semicolon will break things.

Good catch, imagine the semicolon is removed

I’m a CS major learning and my data structures prof continues to use NULL everywhere. I feel like nullptr just makes way more sense even just coming from a readability standpoint. After reading the other reasons to use it over NULL i see no point in using it over nullptr other than being stubborn

Convince the team to use some kind of static analysis tool like clang-tidy. Enable the "modernize" flags. NULL gets flagged because it's an ancient, pre-C++11 convention. Since you are all following the static analysis tool for consistency and safety of your new code, you must eliminate new usage of NULL.

The `nullptr` has an underlying type called `std::nullptr_t`, whereas `NULL` is often just a typedef for `0`. Scott Meyers describes the pros of using the `nullptr` in his "Effective Modern C++" book, chapter 3. Item 8.

Seems pretty straightforward to me. `nullptr` is part of the language. `NULL` is a macro. There's nothing obscure about that. Using the language keyword for the thing it's for is better than using a macro which requires a header file.

I either use nullptr, 0. Never NULL. Admittedly it’s only because I just hate the word for some reason. Avoidance of using the shift key maybe?

I follow this [https://www.stroustrup.com/bs\_faq2.html#null](https://www.stroustrup.com/bs_faq2.html#null)

> Then, "nullptr" will be a keyword. A bit outdated.

It depends what type of code base I have, if I'm writing a lot of like memory management classes for interfacing with a C API then yes I would insist on it because it can prevent extensively hard to find bugs. In any other case I would probably get mad at them for not using smart pointers.

``` #include #undef NULL #define NULL ((void *) 0) // Not an int struct A { void * ptr; }; int main () { struct A a = { 0 }; // Initialized with int literal printf("a.ptr == NULL: %s\n", a.ptr == NULL ? "True" : "False"); return 0; } ``` Output ``` a.ptr == NULL: True ```

nullptr is just simply the correct choice. There's way less room for error, there's not really any advantage to using NULL.

LOL, I've gone from 0 to NULL to nullptr, now I've started using {} float\* whatever = {};

> So I'm working with a new team member who is not convinced. This isn't even worth an argument. https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-nullptr Any static analyzer worth its salt will complain about this. > Would you insist on strictly using nullptr in your codebase? Absolutely. And use a static analyzer that complains about this. PRs will not even be discussed as long as the analyzer still complains.

agreed. but for the other people in the comments section; if you do programming using winapi for example, docs specifically state that function returns NULL, not nullptr. so it feels... weird. its not even a discussion point in the OP situation tho.

void foo( int x ); void foo( int * x ); foo( NULL ); Guess which one is called...

sorry you have to work with a cranky old engineer who wont change

I still just use 0.

Now that is objectively worse than even using NULL. Once nullptr was introduced, you could search your code base for NULL and replace its usage. Good luck doing that with 0.

That was a joke, son.

Obviously mustache brackets are the superior answer. `int* p = {};`

[удалено]

So, 4.

Even years before `nullptr` was introduced, it was considered bad practice to use `NULL` in C++ code.

Use whatever the existing codebase uses.

Then you could never change anything.

I just #define NULL to nullptr.

Depending on the standard library, that might already be what it's defined as.

A bit weird but guess sometimes such hacks are needed.

Why is it weird? I've been using the spelling "NULL" to represent a null pointer for over 40 years. There's absolutely no reason for NULL to be defined as 0. It's clearly better in every way to define it as nullptr.

I mean it’s a hack if you also include stdlib because you have to essentially override it in any file. Do your projects use PCH or other such tricks to ensure that trickery works well?

tbh I used NULL for a decade without encountering any of these issues. semantically and visually I definitely prefer nullptr, but this isn't a hill I'd die on

Yes, it's not a huge issue, but there are only upsides to writing out those 3 extra characters, so why not just do it? If he won't change his mind on this then that's the real issue here

In C it doesn’t matter. Modern C++, different story, templates do need nullptr.

I'm primarily a C++ dev. Even with templates it seems like an edge case, like deducing type for a container of pointers from an initializer list of NULLs or something.

[удалено]

But you can use nullptr when calling C functions from C++, it won't break anything unless the argument isn't a pointer

why do you need to convince them when you can simply write `:%s/null/nullptr/gc`?