Is there any reason not to use the first format?

Is there any reason not to use the first format?

no

The second one is a little more clear, runs no slower than the first, and does not involve and sort of cast to a boolean.
In general, you don't want to write stuff like
if (x == true)
but you should also understand that NULL does not "mean" false, in the same way that a float with value 0 and an integer with value 0 do not mean the same thing.
There's also something to be said about being explicit with your type casting, though I understand that there isn't a "bool" type in C.

>I understand that there isn't a "bool" type in C
There IS a bool type in C though.
It's just that conditionals don't require bool types, and will accept any integer, floating, or pointer type.

if( ptr == nullptr )
{
}


C swine

NULL is defined as nullptr so it's not like it really matters

This thinking is the source of shit software. The 'nullptr' form is formally correct, just like prior to 'nullptr' the

if( ptr == 0 )
{
}


Was correct.

bool wasn't always a C type - it was introduced in the 1999 standard. The only reason why int/char/bool can be implicitly casted between each other is because the type didn't always exist, and so the other types were the only way to express Boolean values. These days OP's first example is just legacy syntax so that old source isn't wrong.

How does using a standard macro make my software shit?

Yes, I know about the history of bool. It's still wrong to say C doesn't have a boolean type.
They're only had 17 years to learn the fact.

No it's not. In C, it's (void *)0. In Sepples, it's just 0.

>They're
They've*

The first one only works if ptr is truthty, the second one passes even if falsy values (false, nil, undefined)

not the other poster, but the idea is that its now an obsolete construct. Though they reach the same means, the actual construct is different.

You're argument is like saying that a functions shouldn't use namespaces because adding a prefix to a function name accomplishes the same thing.

In C ptr gets casted to _Bool. Say a pointer is 2 bytes wide and _Bool is one byte, then a pointer like 0xff00 doesn't match the if clause, but it's not a null pointer.

>imblying that NULL means anything

Kind of a real issue.

That said, I think "ptr != NULL" is more readable.

It's a pointer. The only falsy value is NULL

That's not actually true.

It's common to assign values like 0xFEFEFEFE or 0xDEADBEEF to indicate certain types of disposal.

Not that your software should be seeing those, if it's written correctly, but nonetheless NULL assignment to a pointer generally means something specific.

That's flat out wrong, in many different ways.
>ptr gets casted to _Bool
No it doesn't. Conditionals do not do conversions like that.
Also, logical operators (==, !=, &&, || etc.) are all int.
>Say a pointer is 2 bytes wide and _Bool is one byte
Irrelevant.
>then a pointer like 0xff00 doesn't match the if clause
Yes it does. ANY non-null pointer will be 'true'.
Also, you have the semantics of _Bool completely wrong. Any non-zero value will be converted to 1.

I prefer ptr!=NULL, although both are fine.
I also use '\0' instead of 0 for checking for null terminator.

>it's (void *)0
I believe it's implementation-defined.

>Is there any reason not to use the first format?

Yes. Using the first format requires you to use the C Programming Language, a language that should have been put out to pasture a decade ago.

>I believe it's implementation-defined.
No, it's (void *)0.
However, the underlying representation is implementation defined.
A bit pattern that represents a null pointer doesn't have to be zeros.

The first format is better because it's not dependent on NULL or nullptr, and also works for stuff like shared_ptr and unique_ptr.

If the compiler optimizes them to the same set of instructions there is benefit in using the more explicit expression in any case. Original coding time is negligible compared to time spent on debugging.

So I should be doing
if (condition == true) {
/* do stuff */
}
too?

Are you saying shared_ptr and unique_ptr can't be compared to NULL?!

If it compiles to the same thing yes why not. You may even forget if the variable is boole at some point in the code, or someone else may have trouble following it. It's beneficial to be as explicit as possible for idiots like me to be able to follow your terribly written code.

void func()
{
if (ptr == nullptr)
return;
// do ...
}

vs

void func()
{
if (ptr) {
// do ...
}
}


why nest again if you can early exit with much cleaner looking code

>NULL is defined as nullptr so it's not like it really matters
It's not.

The C standard states that (void *)0 should always be NULL in declarations (leaving it to the compiler to substitute for the real value in all cases of pointers to 0), but does not guarantee that NULL is actually zero from the processors point of view. You cannot rely on stuff like:

if(NULL == 0)

Because it may not evaluate to true. However, you are guaranteed that in an if statement, this will evaluate to false:

int *ptr = NULL;
if(ptr != NULL)

Your only guarantee is that NULL == (void *)0 and that comparing pointers to NULL will behave as if you were comparing an int to 0.

This, by the way, is also why you can sometimes dereference NULL without a segfault and end up in system memory and all sorts of crap.

You could just as easily do
void func() {
if (!ptr) { return; }
// do ...
}

if (ptr != nullptr)
{
// Stuff
}

No retard. C has no bool type.

NULL is NULL, it's not necessarily a boolean false. If you want to do things properly, stick to it instead of experimenting.

Same reason you should always do if (func() != false) {} and not if (func() == true) {} or if (func()) {} because true can be redefined, and who knows when some retard will change the return type.