How does this work without instantiating an object of the Studentclass?

[amit.bolakani.technical]

#include <iostream>
using namespace std;



class Person{
public:
virtual void print () { cout << "In parent" << endl; }
void onlyInPerson() { cout << "Only in Person/parent" <<
endl; }
};

class Student: public Person{
public:
Student() { cout << "Student constructor." << endl; }
void print() { cout << "In child" << endl; }
void onlyInChild() { cout << "Only in Child/Student" <<
endl; }
};

int main()
{
Person* p ;
Student* s;
s->onlyInChild();
return 0;
}

 

[siddhu]

#include <iostream>
using namespace std;

class Person{
public:
virtual void print () { cout << "In parent" << endl; }
void onlyInPerson() { cout << "Only in Person/parent" <<
endl; }

};

class Student: public Person{
public:
Student() { cout << "Student constructor." << endl; }
void print() { cout << "In child" << endl; }
void onlyInChild() { cout << "Only in Child/Student" <<
endl; }

};

int main()
{
Person* p ;
Student* s;
s->onlyInChild();
return 0;



}- Hide quoted text -

- Show quoted text -

Although function is getting called, But its undefined behavior.

 

[David Côme]

#include <iostream>
using namespace std;



class Person{
public:
virtual void print () { cout << "In parent" << endl; }
void onlyInPerson() { cout << "Only in Person/parent" <<
endl; }
};

class Student: public Person{
public:
Student() { cout << "Student constructor." << endl; }
void print() { cout << "In child" << endl; }
void onlyInChild() { cout << "Only in Child/Student" <<
endl; }
};

int main()
{
Person* p ;
Student* s;
s->onlyInChild();
return 0;
}

I'm not sure but for me it's an undefined behaviour

 

[amit.bolakani.technical]

I'm not sure but for me it's an undefined behaviour

It seems to compile and run fine! I'm pretty surprised and it throws
me off a bit in terms of how it runs fine?

 

[amit.bolakani.technical]

It seems to compile and run fine! I'm pretty surprised and it throws
me off a bit in terms of how it runs fine?

Did any of you guys try this with your compiler. I tried it with g++
3.4.4 on cygwin.

 

[Default User]

int main()
{
Person* p ;
Student* s;
s->onlyInChild();
return 0;
}

It's Undefined Behavior to deference an invalid pointer. There is no
defined behavior for Undefined Behavior. It is not a syntax error. It
is not a constraint violation. There is no required diagnostic.




Brian

 

[tragomaskhalos]

It seems to compile and run fine! I'm pretty surprised and it throws
me off a bit in terms of how it runs fine?- Hide quoted text -

That it happens to work is no surprise - onlyInChild does not access
any members, and the method is not virtual, hence the garbage this
pointer is
not dereferenced. Neverthless it's still undefined behaviour.

 

[amit.bolakani.technical]

That it happens to work is no surprise - onlyInChild does not access
any members, and the method is not virtual, hence the garbage this
pointer is
not dereferenced. Neverthless it's still undefined behaviour.

Isin't the garbage this pointer dereferenced to to call the member
function onlyInChild() ?

 

[Vaclav Haisman]

#include <iostream>
using namespace std;



class Person{
public:
virtual void print () { cout << "In parent" << endl; }
void onlyInPerson() { cout << "Only in Person/parent" <<
endl; }
};

class Student: public Person{
public:
Student() { cout << "Student constructor." << endl; }
void print() { cout << "In child" << endl; }
void onlyInChild() { cout << "Only in Child/Student" <<
endl; }
};

int main()
{
Person* p ;
Student* s;
s->onlyInChild();
return 0;
}

The programme compiles because it is well-formed and probably even runs
because the methods actually do not touch anything in the object itself but
your programme is invoking undefined behaviour.

 

[amit.bolakani.technical]

(e-mail address removed) wrote, On 14.12.2007 22:29:





The programme compiles because it is well-formed and probably even runs
because the methods actually do not touch anything in the object itself but
your programme is invoking undefined behaviour.

Ok, so I understand that its undefined behavior. However, is the
garbage this pointer dereferenced to call the member method?

 

[Default User]

Isin't the garbage this pointer dereferenced to to call the member
function onlyInChild() ?

Maybe, maybe not. Who cares?

There. Is. No. Defined. Behavior. For. Undefined. Behavior.

Say that over and over to yourself until you GET IT.





Brian

 

[amit.bolakani.technical]

Maybe, maybe not. Who cares?

There. Is. No. Defined. Behavior. For. Undefined. Behavior.

Say that over and over to yourself until you GET IT.

Brian

No worries Brian GOT IT!
Thanks for all your help guys. Appreciate it.

 

[Erik Wikström]

Ok, so I understand that its undefined behavior. However, is the
garbage this pointer dereferenced to call the member method?

Do you see 'this' (or any other members) mentioned anywhere in
onlyInChild()? If you do not, why would it be dereferenced?

 

[tragomaskhalos]

Isin't the garbage this pointer dereferenced to to call the member
function onlyInChild() ?- Hide quoted text -

OK, my original reply wasn't detailed enough.
Others have said that this is UB but you are quite correctly
still wondering why it happend to work with your compiler.
The key is that the compiler is likely producing code something akin
to this:

//SOURCE:
// void Student:nlyInChild() { cout << "Only in Child/Student" <<
endl; }
//COMPILER:
void __Student_onlyInChild(__this) {
/* ... stuff that NEVER USES __this */
}

//SOURCE s->onlyInChild(); // nb s is uninitialised ...
//COMPILER:
__Student_onlyInChild(s); // nb s is NOT dereferenced

HTH

 

[Markus Moll]

Hi

Ok, so I understand that its undefined behavior. However, is the
garbage this pointer dereferenced to call the member method?

That's just one of the things that is undefined.

Markus

 

[Pete Becker]

OK, my original reply wasn't detailed enough.
Others have said that this is UB but you are quite correctly
still wondering why it happend to work with your compiler.
The key is that the compiler is likely producing code something akin
to this:

Maybe. Speculating about why something whose behavior is undefined
happens to do what a naive programmer guessed it would do is generally
pointless. Undefined means undefined. Nothing more. The reason that it
"works" is pure accident. (That's the screed for beginning and
intermediate programmers.)

 

[tragomaskhalos]

Maybe. Speculating about why something whose behavior is undefined
happens to do what a naive programmer guessed it would do is generally
pointless. Undefined means undefined. Nothing more. The reason that it
"works" is pure accident. (That's the screed for beginning and
intermediate programmers.)

Well that's probably a good philosophy in the general case, but here
the OP accepted the undefinedness of the code but was clearly baffled
as to how it *could ever* have worked; seeing how a compiler might
realistically have treated the code so as to produce the observed
effect
is often valuable - when taken with the usual caveats. Otherwise one
is
left with a helpless feeling that it's all magic, which can only
dishearten the questioner and deter experimentation.

 

[Pete Becker]

Well that's probably a good philosophy in the general case, but here
the OP accepted the undefinedness of the code but was clearly baffled
as to how it *could ever* have worked; seeing how a compiler might
realistically have treated the code so as to produce the observed
effect
is often valuable - when taken with the usual caveats. Otherwise one
is
left with a helpless feeling that it's all magic, which can only
dishearten the questioner and deter experimentation.

Once you're in the realm of undefined behavior, it is all magic, unless
you're skills are advanced enough to analyze machine instructions.
That's not a useful exercise for beginners.