Need help for NULL constant in C++

[love307]

Hi all!
I have one question, want to have your help for answer it.

This is a problem:
class A
{
public:
int n;
void printMessage()
{
printf("hello world");
}
};

void main()
{
A *a = NULL;
a->printMessage();
}

I don't know why when debug: a = 0x0000000;
but we still call printMessage function.
Thank for your help!

Bui Minh Tu

 

[Kai-Uwe Bux]

Hi all!
I have one question, want to have your help for answer it.

This is a problem:
class A
{
public:
int n;
void printMessage()
{
printf("hello world");
}
};

void main()
{
A *a = NULL;
a->printMessage();
}

I don't know why when debug: a = 0x0000000;

Because you set a = NULL. What do you expect?

but we still call printMessage function.

You are dereferencing a null pointer. Thus, you have undefined behavior,
i.e., everything (including what you observed) can happen. (In particular,
the program is not required to crash, which is why this kind of bug easily
goes uncaught. Run your program through a memory checker like valgrind to
check for mishaps like this.)

What is happening behind the scenes is possibly something like this: the
compiler knows the static type of a to be A*. The function printMessage()
is non-virtual and the compiler just deduces what code needs to be executed
from the static type.


Best

Kai-Uwe Bux

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

Hi all!
I have one question, want to have your help for answer it.

This is a problem:
class A
{
public:
int n;
void printMessage()
{
printf("hello world");
}
};

void main()
{
A *a = NULL;
a->printMessage();
}

I don't know why when debug: a = 0x0000000;
but we still call printMessage function.
Thank for your help!

As Kai-Uwe Bux explained this is undefined behaviour, the "problem" with
your code is that printMessage() does not access any members of the
class, if you modify it to something like

void printMessage()
{
printf("n: %d", n);
}

you will get your expected crash. In general, a function that does no in
any way access another member of the class should probably be static.

 

[year1943]

As Kai-Uwe Bux said, your method is not virtual, so it's call

a->printMessage();

is realized as just like
A:rintMessage(& a) ;
- so it got your NULL as first ("invisible") argument "this". As you
don't use "this" (even implicitly) in your method - NULL is not used
and u have no trouble.

 

[red floyd]

As Kai-Uwe Bux said, your method is not virtual, so it's call
is realized as just like
A:rintMessage(& a) ;
- so it got your NULL as first ("invisible") argument "this". As you
don't use "this" (even implicitly) in your method - NULL is not used
and u have no trouble.

Wrong. It's undefined behavior, so it can do anything, including
crashing, working "as expected" (whatever that is), or doing anything
else within (or out of) reason.

 

[year1943]

(e-mail address removed) wrote:
Wrong. It's undefined behavior,

Did I anywhere say this is defined behaviour?
I did explaned what happend with code of question mostly possible.
It's right way.
You gave formal point w/o explanation. Generally it's wrong way of
teaching and answering.
Kai-Uwe Bux said long before my and you:

You are dereferencing a null pointer. Thus, you have undefined behavior

Read carefully.

 

[red floyd]

Did I anywhere say this is defined behaviour?
I did explaned what happend with code of question mostly possible.
It's right way.
You gave formal point w/o explanation. Generally it's wrong way of
teaching and answering.
Kai-Uwe Bux said long before my and you:
Read carefully.

And you are wrong. There is no requirement for an "implied" parameter.
His implementation *may* do things that way, but how do you know that
for a fact?

 

[Hemu]

Hi all!
I have one question, want to have your help for answer it.

This is a problem:
class A
{
public:
int n;
void printMessage()
{
printf("hello world");
}

};

void main()
{
A *a = NULL;
a->printMessage();

}

I don't know why when debug: a = 0x0000000;
but we still call printMessage function.
Thank for your help!

Bui Minh Tu

one possible reason of this may be that the memory for a varibale is
allocated at the run time but compiler , at the compile time resolves
the call for a function
and hard code it in the binary file at the build time and thats why I
believe this code is working.

 

[Pete Becker]

one possible reason of this may be that the memory for a varibale is
allocated at the run time but compiler , at the compile time resolves
the call for a function
and hard code it in the binary file at the build time and thats why I
believe this code is working.

Well, the code is "working" in the broad sense that it's doing
something reasonable that can be explained without excessive logical
contortions. Nevertheless, it isn't "working" in the narrow sense of
doing what the language definition says that it does, because the
language definition doesn't say what it should do. The code is simply
wrong, and speculating about why it does what it does is wasted time.