2

I created a NULL pointer of class App, but somehow the method of the NULL object(of App) is working. Here is my code:

#include "App.h"
#include <iostream>
using namespace std;
int main()
{
    App* pointer = NULL;
    pointer->print();

    system("pause");
}

Attached the Header file

#pragma once
#include <iostream>
using namespace std;
class App
{
private:
    int x;
    int y;
public:
    App(void);
    ~App(void);
    App(int a, int b)
    {
        x=a;
        y=b;
    }
    void print()
    {
        cout<<"hello world"<<endl;
    }
};

The running result an the screen in : hello world. Why is that?

Shafik Yaghmour
  • 154,301
  • 39
  • 440
  • 740
benny perl
  • 41
  • 3

6 Answers6

2

Undefined behaviour is just that - undefined. Anything can happen, including the appearance of behaving correctly.

For your case, specifically, you might want to check out the generated assembly from your program. You'll probably find that the compiler has optimized your code and inlined that printout or called it directly rather than actually invoking it through a pointer/table lookup.

Carl Norum
  • 219,201
  • 40
  • 422
  • 469
  • But why? no logical explanation? – benny perl Apr 25 '13 at 14:26
  • You'll have to look at what your compiler did to figure that out (see my second paragraph). Your question doesn't have enough information for us to go on on that front, I'm afraid. – Carl Norum Apr 25 '13 at 14:26
  • 4
    @bennyperl You may also notice that the compiler treats methods as relatively standard function calls that simply pass the `this` pointer through a register or as the first argument. As the function in question didn't access `this`, it would blindly not notice the `nullptr` `this`. As the C++ standard states what you are doing is undefined behavior, the compiler is free to generate code that does anything it wants -- segfault, format your hard drive, mail your bank account information to Aruba -- or, in this case, ignore the `this` pointer being `nullptr`. Relying on this is a bad idea. – Yakk - Adam Nevraumont Apr 25 '13 at 14:27
  • 1
    @bennyperl: It can't be stressed enough that Undefined Behaviour means there can't be any logical explanation: **anything** can happen including formatting your hard drive or exploding the moon. Any "logical" explanation is likely to be right only on a limited number of platforms, and to be wrong on quite a number of other platforms (even the very same executable may behave differently on different OS versions if UB is involved!). Trying to reason with UB is futile, the only thing you can reasonably do is to avoid triggering it. – syam Apr 25 '13 at 15:20
1

Invoking a method on a NULL pointer is undefined behavior so anything may happen. You should never count on the fact that the code will always produce this output. Always try to avoid such situations.

Ivaylo Strandjev
  • 69,226
  • 18
  • 123
  • 176
1

Dereferenceing a NULL pointer is undefined behaviour. You should not expect your program not to 'work' just because you do this.

In this case your print function does not 'use' the this pointer so your code executes as you expected. But you should not rely on this, undefined behaviour means exactly what it says.

john
  • 7,897
  • 29
  • 27
1

This is undefined behavior, this thread explains why it most likely works, the basic explanation is that it will probably be transformed into something similar to:

void _App_print( App* this ); 

and since you are not using this it works.

Community
  • 1
  • 1
Shafik Yaghmour
  • 154,301
  • 39
  • 440
  • 740
1

It is undefined behavior. The implementation is able to work in this toy example because print does not access member variables and is a non-virtual function.

Mark Borgerding
  • 8,117
  • 4
  • 30
  • 51
0

Because print does not (even implicitly) access any data behind the "this" pointer.

oseiskar
  • 3,282
  • 2
  • 22
  • 22