Is there any reason not to use the first format?

>>57959010
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.

>>57959450
>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.

>>57959010

if( ptr == nullptr )
{
}

C swine

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

>>57960007
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.

>>57959462
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.

>>57960052
How does using a standard macro make my software shit?

>>57960077
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.

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

>>57960109
>They're
They've*

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

>>57960081
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.

>>57959010

>imblying that NULL means anything

Kind of a real issue.

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

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

>>57960148

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.

>>57960142
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.

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

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

>>57959010
>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.

>>57960192
>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.

>>57959010
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.

>>57959010
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.

>>57960505
So I should be doing

if (condition == true) {
    /* do stuff */
}

too?

>>57960400

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

>>57960559
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.

>>57959010
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

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

>>57960212
>>57960192
>>57960109

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.

>>57963413
>>57960212
>>57960192
>>57960109

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.

>>57962529
You could just as easily do

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

>>57959010

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

>>57959462
No retard. C has no bool type.

>>57959010
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.