How this can be possible ?
WantToKnowMore
class object. Still it executes the function.
And note that with VS 2005 compiler its giving 2 different results on
2 different PCs. In one PC it gives run time error (expected) and in
another PC it executes !
#include <iostream>
using namespace std;
class foo
{
public:
void greet(){cout << "Hello" << endl;}
};
int main()
{
foo* f;
f->greet(); // In one PC this function getting executed with printing
"Hello". How ???
return 0;
}
Michael Doubez
> I'm calling a function with a class pointer without assigning to any
> class object. Still it executes the function.
From 5.2.5/3, f->greet() is equivalent to (*f).greet(). You are
deferencing an unitialized pointer, this is UB so everything can
happen.
For your compiler, I guess the expression is equivalent to a free
function call because 'this' is passed as a hidden parameter and not
used in the function.
Ron
> On 1 sep, 11:06, WantToKnowMore <urprad...@gmail.com> wrote:
>
> > I'm calling a function with a class pointer without assigning to any
> > class object. Still it executes the function.
>
> From 5.2.5/3, f->greet() is equivalent to (*f).greet(). You are
> deferencing an unitialized pointer, this is UB so everything can
> happen.
Yep, one of the insidious modes of undefined behavior is that it
silently
appears to work fine TODAY. Tomorrow or when you least suspect it
may
be a different story.
Juha Nieminen
> I'm calling a function with a class pointer without assigning to any
> class object.
Member functions are not stored inside the object. They are a bit like
normal functions, just silently taking an additional parameter (the
object in question).
Of course if the member function in question tries to access the
uninitialized object, you will get a crash or worse.
Joshua Maurice
Though virtual members are stored inside the object, quote unquote,
for the common implementation, so if "greet" was declared virtual,
then I would expect the OP's program to crash.
Michael Doubez
I would not: in the example, the compiler knows the underlying type
and therefore is not required to use the virtual call. I expect that
in practice, it doesn't and simply directly call the most derived
member function.
--
Michael
Joshua Maurice
I think you greatly over-estimate the effectiveness of current C++
compilers. I would guess that most do not do such program analysis to
inline virtual functions, nor use a virtual lookup cache, etc. At
least, Visual Studios 2008 does not, nor g++ version 4.1.2. Both
produced programs from the following source which crashed / seg
faulted when compiled with the high optimizations (-O3 for g++, and
equivalent options for Visual Studios):
#include <iostream>
using namespace std;
class foo
{
public:
virtual void greet(){cout << "Hello" << endl;}
};
int main()
{ foo* f = 0;
f->greet();
}
Juha Nieminen
> Though virtual members are stored inside the object
Well, not really. Virtual members (well, pointers to them, to be
exact) are stored in an external table (which is shared by all the
objects of that type) and what is stored in the object is only a pointer
to that table.
The effect is basically the same, though.
Joshua Maurice
On Sep 1, 3:00 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> Though virtual members are stored inside the object, quote unquote,
From http://idioms.thefreedictionary.com/quote,+unquote
> quote, unquote (British, American & Australian) also quote, end quote (American)
> something that you say when you want to show that you are using someone else's phrase, especially when you do not think that phrase is true
Thank you for attempting to correct me with a great out of context
quote (by snipping off the next two words). I already said what you
were trying to correct, so we're both right, but you made it sound as
though I was wrong, and I take some offense to that.