How does this work without instantiating an object of the Student class?
amit.bolaka...@gmail.com
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
>
> - Show quoted text -
Although function is getting called, But its undefined behavior.
David Côme
wrote:
I'm not sure but for me it's an undefined behaviour
amit.bolaka...@gmail.com
> On Fri, 14 Dec 2007 22:29:32 +0100, <amit.bolakani.techni...@gmail.com>
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.bolaka...@gmail.com
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
>
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.bolaka...@gmail.com
wrote:
Isin't the garbage this pointer dereferenced to to call the member
function onlyInChild() ?
Vaclav Haisman
because the methods actually do not touch anything in the object itself but
your programme is invoking undefined behaviour.
--
VH
amit.bolaka...@gmail.com
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.bolaka...@gmail.com
No worries Brian :) GOT IT!
Thanks for all your help guys. Appreciate it.
Erik Wikström
Do you see 'this' (or any other members) mentioned anywhere in
onlyInChild()? If you do not, why would it be dereferenced?
--
Erik Wikström
tragomaskhalos
>
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::onlyInChild() { 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
amit.bolaka...@gmail.com wrote:
> 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
<dave.du...@logicacmg.com> said:
>
> 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.)
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)
tragomaskhalos
> On 2007-12-15 04:36:30 -0500, tragomaskhalos
>
> > 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.)
>
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
<dave.du...@logicacmg.com> said:
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.