Which is more efficient
if(!var_name)
or
if(var_name == NULL)
+7
A:
It doesn't matter. Both will be very efficient, no matter what compiler you use, and for most compilers will compile to exactly the same code. If this is of genuine concern to you, take a look at the assembly/machine code emitted by your specific compiler.
anon
2010-02-08 10:12:41
And I doubt that any potential difference will ever be significant.
Brian Rasmussen
2010-02-08 10:13:32
@Brian Rasmussen: It can heavily depend on the comppiler and the requirements. Really if one cares so much he should look into the disassembly.
sharptooth
2010-02-08 10:16:04
+5
A:
It does not matter.
Changing this would be micro optimisation and unlikely to change the performance of your app (unless you have actualy checked this is the bottle neck). Other then that I would bet the compiler would change this statement into the best one (if it mattered), so I would use the syntax that you prefer.
EKS
2010-02-08 10:14:44
A:
I would not use a compiler which generates different code for performance sensitive stuff.
AProgrammer
2010-02-08 10:15:22
A:
In case var_name is a pointer and you're compiling for some embedded system with a crappy non-optimizing compiler, var_name == NULL will be faster, because a cast to boolean followed by negation followed by comparison to true will be slower than plain value comparison. In case of about every single other compiler they will get optimized away to the same code.
SF.
2010-02-08 10:17:20
Obviously a crappy non-optimising compiler can make a horlicks of any code it likes, but 6.5.3.3/5 of n1256 says, "The expression !E is equivalent to (0==E)". So it's not just negligence, a C compiler actually has to go out of its way for the ! operator to produce code that converts to boolean type and then compares to true, since that isn't how the ! operator is defined. Could be different in C++, I can't remember.
Steve Jessop
2010-02-08 11:08:31
+16
A:
Both will compile to the same code. Your choice of which to use should depend on which is most readable.
This version:
if(var_name == NULL)
should only be used when var_name is a pointer, otherwise you will confuse anyone who reads your code in the future. Some compilers might complain if you use this on a non-pointer.
This one:
if(!var_name)
should be used in cases when you are logically treating var_name as a boolean (true/false) value. This can include when var_name is a pointer, since NULL is the value for "false" or undefined pointers.
If var_name is an integer, then I would choose a third option:
if(var_name == 0)
as I find it expresses intent more clearly.
Paul Stephenson
2010-02-08 10:21:07
Actually, they may compile to different assembly language instructions, depends on the processor. Some processors may have a *Jump If Not Equal* (*Jump If Not Zero*) some may not. In either case, this is a trivial optimization compared to requirements or design optimizations. Optimizations at this level are platform specific.
Thomas Matthews
2010-02-08 19:32:36
A:
if(var_name == NULL)
is more efficient because the guy (or your own self in the future) who reads that code will immediately see that:
var_nameis a pointer- you're performing a null check
on the other case the intent and variable type is completely ambiguous. Is it a boolean? is it an int? Is it a pointer? are you checking against zero? or a true/false condition?
These questions are answered right away with the notation above, and it should be used whenever the intent is null checking a pointer.
ssg
2010-05-27 17:20:49
... no. Just no. Number of characters != readability or better. Let's see, which one tells me more, `dlsym` or `GetProcAddress`?
Billy ONeal
2010-09-21 03:24:58
My point was that the only difference between the two was the number of characters they take, and that there's no difference to the compiler, much like differences in whitespace... using a play on the meaning of "efficient". I happen to like the first a lot better but it's certainly a matter of taste.
R..
2010-09-21 19:51:15
A:
If 'var' is of a UDT, then the choice of which to use would be guided more by which of these operators the class offers rather than efficiency (which I believe is answered by most of the responses above)
Chubsdad
2010-09-21 06:12:18