A simple class

[Giancarlo Berenz]

Hi:

Recently i write this code:

class Simple
{
private:
int value;
public:
int GiveMeARandom(v oid);
int GiveMeValue(voi d);
}

int Simple::GiveMeA Random(void)
{
return rand()%100;
}

int Simple::GiveMeV alue(void)
{
return this->value;
}

....

int main()
{
Simple * Object = NULL;
printf("%d",Obj ect->GiveMeARandom( ));
return 0;
}
Well, this code compile's ok and when i tried to use them... works!,
but my question is how i can access to a method of an object that not
exist in memory?. In the other hand, if you try to access to the other
method like this:

printf("%d",Obj ect->GiveMeValue()) ;

it crash!, and obviusly it crash because the object not exist in
memory and when you attempt to access to it variable "value" it read's
the 0x00000 direction.

But my question is about the method, the method's in C++ classes
exists without produce any object in code?. I'm thinking about and i
have a possibly explanation but what do you think about?.

Thanks
Giancarlo Berenz

[Phlip]

Giancarlo Berenz wrote:

Simple * Object = NULL;
printf("%d",Obj ect->GiveMeARandom( ));

Well, this code compile's ok and when i tried to use them... works!,
but my question is how i can access to a method of an object that not
exist in memory?

Because C++ is very efficient and very mechanical. It will not check many
details of your output code, including whether a pointer is correctly
seated. That's because C++ must compete with assembler (where you can get
away with much worse things), while compiling huge programs in reasonable
time.

So, at -time, C++ inserted no opcodes into the output program that checked
where Object points. The previous line could have pointed it to a legitimate
object, or dangled it, or NULLed it, like you did.

When you write a broken program like that, you get "undefined behavior".
That means the program could work the way you expect, or work another way,
or crash, or the program could explode the nearest toilet.

printf("%d",Obj ect->GiveMeValue()) ;

it crash!, and obviusly it crash because the object not exist in
memory and when you attempt to access to it variable "value" it read's
the 0x00000 direction.

And the other function had no reason to touch the presumed object as it ran,
so it accidentally appeared to work correctly.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

[Michael DOUBEZ]

Phlip a écrit :

Giancarlo Berenz wrote:

> Simple * Object = NULL;
printf("%d",Obj ect->GiveMeARandom( ));

>Well, this code compile's ok and when i tried to use them... works!,
but my question is how i can access to a method of an object that not
exist in memory?

Because C++ is very efficient and very mechanical. It will not check many
details of your output code, including whether a pointer is correctly
seated. That's because C++ must compete with assembler (where you can get
away with much worse things), while compiling huge programs in reasonable
time.

[snip]

It has nothing to do with assembly.
IMO the compiler has no way of knowing whether the pointer is correct or
not. It doesn't know about register memory layout by example and I can
perfectly design a plateform with memory starting at 0x0000000 in which
case deferencing NULL is valid.

The only thing the compiler can do is checking the type and that is
already a good thing C++ is strongly typed.

Michael

[Serge Paccalin]

Le 06.03.2007 03:59, Giancarlo Berenz a ecrit:

Hi:

Recently i write this code:

class Simple
{
private:
int value;
public:
int GiveMeARandom(v oid);
int GiveMeValue(voi d);
}

int Simple::GiveMeA Random(void)
{
return rand()%100;
}

int Simple::GiveMeV alue(void)
{
return this->value;
}

....

int main()
{
Simple * Object = NULL;
printf("%d",Obj ect->GiveMeARandom( ));
return 0;
}
Well, this code compile's ok and when i tried to use them... works!,
but my question is how i can access to a method of an object that not
exist in memory?. In the other hand, if you try to access to the other
method like this:

printf("%d",Obj ect->GiveMeValue()) ;

it crash!, and obviusly it crash because the object not exist in
memory and when you attempt to access to it variable "value" it read's
the 0x00000 direction.

But my question is about the method, the method's in C++ classes
exists without produce any object in code?. I'm thinking about and i
have a possibly explanation but what do you think about?.

Since you write a definition for your functions, they can be compiled
and their code can exist in memory. The object they "belong to" is just
a pointer passed as a hidden parameter, and if that parameter is not
used, it may work on some implementations , like yours.

In other words, your code is *very roughly* similar to the following:

class Simple
{
private:
int value;

friend int Simple_GiveMeAR andom(Simple *);
friend int Simple_GiveMeVa lue(Simple *);
}

int Simple_GiveMeAR andom(Simple * /*unused*/)
{
return rand() % 100;
}

int Simple_GiveMeVa lue(Simple *that)
{
return that->value;
}

.....

int main()
{
Simple * Object = NULL;
printf("%d",Sim ple_GiveMeARand om(Object));
return 0;
}


--
Serge Paccalin
<se************ @easyvisio.net>

[Phlip]

Michael DOUBEZ wrote:

It has nothing to do with assembly.

C++ doesn't compete with Assembler? Then why is everything and its
uncle "undefined" ?

IMO the compiler has no way of knowing whether the pointer is correct or
not. It doesn't know about register memory layout by example and I can
perfectly design a plateform with memory starting at 0x0000000 in which
case deferencing NULL is valid.

The compiler could know that if it added extra opcodes. That would
slow down all the systems that use C++ in speed-sensitive contexts. So
those systems would have to use the next faster language, Assembler.
So, to compete with Assembler, C++ permits undefined behavior.

--
Phlip

[Gavin Deane]

On 6 Mar, 08:16, Michael DOUBEZ <michael.dou... @free.frwrote:

It has nothing to do with assembly.
IMO the compiler has no way of knowing whether the pointer is correct or
not. It doesn't know about register memory layout by example and I can
perfectly design a plateform with memory starting at 0x0000000 in which
case deferencing NULL is valid.

It's a bit academic, but I don't believe that's true. As I understand
it, dereferencing a null pointer *always* leads to undefined
behaviour. If the target hardware understands 0 to be a valid memory
address, it is the compiler's job to manage the magic that allows the
programmer to use null pointer constants and null pointer values as
special entities as defined in the standard while the underlying
hardware can still use the piece of memory it understands to be at
address 0.

Gavin Deane

[Bo Persson]

Giancarlo Berenz wrote:

Hi:

Recently i write this code:

class Simple
{
private:
int value;
public:
int GiveMeARandom(v oid);
int GiveMeValue(voi d);
}

int Simple::GiveMeA Random(void)
{
return rand()%100;
}

int Simple::GiveMeV alue(void)
{
return this->value;
}

...

int main()
{
Simple * Object = NULL;
printf("%d",Obj ect->GiveMeARandom( ));
return 0;
}
Well, this code compile's ok and when i tried to use them... works!,

It just seems to work. :-)

There is an implicit contact between the programmer and the compiler - you
provide legal code, and the compiler translates it correctly.

When you are dereferencing a null pointer, you have broken the contract with
the compiler. It is then free to do anything at all, like print a value
anyway. Or crash.
Technically, it is "Undefined behaviour". Anything can happen.
Bo Persson

[Michael DOUBEZ]

Phlip a écrit :

Michael DOUBEZ wrote:

>It has nothing to do with assembly.

C++ doesn't compete with Assembler? Then why is everything and its
uncle "undefined" ?

It is undefined because it is compiler/plateform/optimisation dependant.

>

>IMO the compiler has no way of knowing whether the pointer is correct or
not. It doesn't know about register memory layout by example and I can
perfectly design a plateform with memory starting at 0x0000000 in which
case deferencing NULL is valid.

The compiler could know that if it added extra opcodes. That would
slow down all the systems that use C++ in speed-sensitive contexts. So
those systems would have to use the next faster language, Assembler.
So, to compete with Assembler, C++ permits undefined behavior.

What opcode would it add to know whether a pointer is valid or not ?
That would mean the processor is aware of the plateform it is on and of
the layout of various component.

Those opcode would be related to bios or some other metaconfigurati on
and I have never seen such thing. Though component are more and more
communicating and that will perhaps be the case one day.

C++ permits undefined behavior sometimes to allow optimisation as you
say but also because some things are plateform dependant, some would
unnecessarily constaint the compiler or could not be portable.
Michael

[Michael DOUBEZ]

Gavin Deane a écrit :

On 6 Mar, 08:16, Michael DOUBEZ <michael.dou... @free.frwrote:

>It has nothing to do with assembly.
IMO the compiler has no way of knowing whether the pointer is correct or
not. It doesn't know about register memory layout by example and I can
perfectly design a plateform with memory starting at 0x0000000 in which
case deferencing NULL is valid.

It's a bit academic, but I don't believe that's true. As I understand
it, dereferencing a null pointer *always* leads to undefined
behaviour. If the target hardware understands 0 to be a valid memory
address, it is the compiler's job to manage the magic that allows the
programmer to use null pointer constants and null pointer values as
special entities as defined in the standard while the underlying
hardware can still use the piece of memory it understands to be at
address 0.

True. It was just a (bad) example.
Deferencing NULL is undefined behavior and NULL should evaluate to
integer 0 so using hardware at 0 would be a problem.

Let say I can put my device at address 0xDEAD0000 :)
Who is to say a pointer value is invalid ?

Michael

[=?iso-8859-1?q?Erik_Wikstr=F6m?=]

On 6 Mar, 17:05, "Gavin Deane" <deane_ga...@ho tmail.comwrote:

On 6 Mar, 08:16, Michael DOUBEZ <michael.dou... @free.frwrote:

It has nothing to do with assembly.
IMO the compiler has no way of knowing whether the pointer is correct or
not. It doesn't know about register memory layout by example and I can
perfectly design a plateform with memory starting at 0x0000000 in which
case deferencing NULL is valid.

It's a bit academic, but I don't believe that's true. As I understand
it, dereferencing a null pointer *always* leads to undefined
behaviour. If the target hardware understands 0 to be a valid memory
address, it is the compiler's job to manage the magic that allows the
programmer to use null pointer constants and null pointer values as
special entities as defined in the standard while the underlying
hardware can still use the piece of memory it understands to be at
address 0.

Yes, it's because the integer value 0 can be cast to a pointer, but
that pointer does not necessarily have to have the value of 0, the
requirement is that its value is distinguishable from all other
pointer values.

--
Erik Wikström