Now what does the extra = nullptr's give you? Next to nothing.

I would expect the compiler to optimize away those lines anyhow (unless the pointer is dereferneced later, which would be bad, nulled or not), so I would say they do absolutely nothing...

Aside from destructors though, I believe the added safety net is advantageous.

I don't see what is safe about hiding logic errors in your code...

I don't see what is safe about hiding logic errors in your code...

It's not hiding logical errors if it alerts you that's something is wrong. As was stated earlier, the program might not just crash but rather corrupt other memory and cause issues later on. How isn't that safe? What is your view on assertions then if you believe a simple pointer validity check is pointless? It helps to debug. You should remove it in the final product if it isn't absolutely necessary. I still stand by my belief in setting all pointers to null if they are no longer in use. It's just a style, and I'm sure that there are many professional software developers who do the same. It's just a preference.

It's not hiding logical errors if it alerts you that's something is wrong.

But it doesn't alert you? Just does nothing if the case would appear, meaning you wouldn't catch it.

What is your view on assertions then if you believe a simple pointer validity check is pointless?

There might be a few assertions in my code to check a pointer is not null, to make sure an api is not misused, but even those are really a bit pointless, because if the pointer is not allowed to be null, the api should be redesigned to use references instead.

It is pointless to do, because you can by design guarantee that the pointer never is invalid.

Making sure all ownerships are clearly defined, and objects sensibly organised and passed around and used, will make sure all pointers and references are valid when they need to be, no need to check.

Though I have to admit, this was a lot harder to do before C++11 and std::unique_ptr.

std::unique_ptr helps to enforce the ownership structure you define.

Just using raw pointers you have to keep careful track of it yourself (with comments or notes or memory).

There is one case where a check is needed, and that is when null is a valid value for the pointer, which is a perfectly reasonable case, though not that common (and really the only case when a raw pointer might be the tool for the job in C++11)

But thats not what we are discussing, we are discussing trying to detect if the pointer is in an invalid state.

Though as mentioned in this thread, its not really possible to catch all cases of invalid state of the pointer, so it is better to design your program such that the pointer never can be invalid.

(c++ nazi off)

I don't really care that much which style you prefer coding by, and I'm sure many great software engineer have preferred nulling pointers excessively.

Though when I encounter it in code, I get worried the developer didn't put much thought into the ownerships of objects, and that there might be serious issues with it...

But it doesn't alert you? Just does nothing if the case would appear, meaning you wouldn't catch it.

I misspoke with that. Thank you for pointing that out. I should of said it presents the opportunity to alert you if you implement that.

Please keep in mind I am by no means disagreeing with mostly what you have said. I agree that proper design and structure will eliminate nearly all of the cases where a pointer may be invalid. I agree that using smart pointers are beneficial and do away with most of the management tasks of using raw pointers.

I've used COM pointers in the past for wrapping DirectX pointers, but that's the extent of my experience. I understand the concept of them and how they work. I just never encountered issues using raw, so I never switched over. Why fix it if it isn't broken, right?