The Weird and The Wonderful

class Dummy{
public:
    void CheckNull(){
        if(!this)
           std::cout << "This is NULL!";
    }
};

Dummy* dummy = 0;
dummy->CheckNull();

dan neely wrote:

C++ lets you set the this object in the parameters instead of always using the object the method is called on?

void Dummy_CheckNull(Dummy* this);

class NullCall {
public:
    char PublicMethod(int x) {
         return (char)x; }
};

NullCall::PublicMethod(12);

TheScientistIsDead wrote:

would this be another example?

Kurdy Malloy wrote:

It made me wonders if the compiler was smart enough to ...

harold aptroot wrote:

how can you see what code it produces?

Luc Pattyn wrote:

It isn't a compiler's duty to guess at what the programmer intended, it should do so only when reporting error and warning messages ("Are you missing a ;").

mov eax,[_i] ; Fetch value before increment
inc dword [_i] ; Do increment
mov [_i],eax ; Store fetched value

supercat9 wrote:

Wouldn't a more efficient implementation be to simply do nothing, given the lack of a sequence point between the increment and the assignment? Not that I'd generally expect a compiler to find that optimization, but I would have expected code like: mov eax,[_i] ; Fetch value before increment inc dword [_i] ; Do increment mov [_i],eax ; Store fetched valuewhich would, of course, effectively do nothing.

BTW, is there any guarantee about the behavior of "do_something(var++)" if do_something references var? What about "i=++i"? Even though it's hard to imagine that "i=++i;" would do anything other than increment "i", I don't think there's any guarantee that it won't?

CurtD wrote:

do_something(var++) is going to push the current var on the stack, call do_something, then inc var. Nothing strange about that.

CurtD wrote:

This code doesn't "do nothing"

supercat9 wrote:

If the variable i is equal to five before the statement, "i = i++;" is executed, would it not be legitimate for the compiler's generated code to read i (five), increment i (yielding and storing six), and then store the read value back to i (setting it back to 5)? If the variable i is not volatile, would not a legitimate optimization thus be to eliminate the statement altogether?

supercat9 wrote:

Out of curiosity, I wonder if there are any compilers which do not always update a variable used with a pre-increment before making use of the pre-incremented value? It's possible to contrive examples where the optimal code would in fact use (var+1) in the expression and then later store the incremented value to the variable, but I doubt compilers would find such optimizations.

void donothing()
{
   int i = 5;
   i++;
}