Menu
Browsing among some legacy code I've found such function:
static inline bool EmptyFunc() { return (void*) EmptyFunc == NULL; } What are the differences from this one:
static inline bool EmptyFunc() { return false; } This code was created to compile under several different platforms, like PS2, Wii, PC... Are there any reason to use the first function? Like better optimization or avoiding some strange compiler misbehavior?
217
But even with that lib, field.equals (null) is still almost always an issue :P. Because equal is a function derived from Object class, this function compares items of the class. if you use it with null it will return false cause cause class content is not null.
The basic rule is simple: null should only be allowed when it makes sense for an object reference to have 'no value associated with it'. (Note: an object reference can be a variable, constant, property (class field), input/output argument, and so on.)
It's the only object reference we can write literally in code. So Object a = null; Object b = null; means that a == b is true, because both variables contain the same object reference (the single universal blank one). if you invoke .equals () on null you will get NullPointerException
null is a fundamental concept in many programming languages. It is ubiquitous in all kinds of source code written in these languages. So it is essential to fully grasp the idea of null . We have to understand its semantics and implementation, and we need to know how to use null in our source code.
Semantically both functions are the same: they always return false*. Folding the first expression to a constant value "false" is completely allowed by the standard since it would not change any observable side-effects (of which there are none). Since the compiler sees the entire function it also free to optimize away any calls to it and replace it with a constant "false" value.
That is, there is no "general" value in the first form and is likely a mistake on the part of the programmer. The only possibility is that it exploits some special behaviour (or defect) in a specific compiler/version. To what end I don't know however. If you wish to prevent inlining using a compiler-specific attribute would be the correct approach -- anything else is prone to breaking should the compiler change.
(*This assumes that NULL is never defined to be EmptyFunc, which would result in true being returned.).
130
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
