How are functions organized in c++

[Ranjay]

Hi Everyone,

I have this following class

class xx{
public:
int func(){}
};

I have a main as follows

int main(){
xx x1,x2;
x1.func();
x2.func();
}

My questions ?
============

How does the c++ compiler organise the functions inside a class ?.

Are they stored as function pointers something like this
int (xx::func) () something the user cannot figure out and to him/her
it appears as object.member_function() e.g x1.func()

While we were discussing all this some one told me that x1.func()
actually resolves to x1.func(*this)

Still another guy was of the opinion that x1.func() resolves to
x.func(&x1).

All this provides different thoughts and different interpretations

Please provide some clarity on how the compiler would actually organise
it

My thanks in advance

Thanks
Ranjaya

[Rolf Magnus]

Ranjay wrote:

Hi Everyone,

I have this following class

class xx{
public:
int func(){}
};

I have a main as follows

int main(){
xx x1,x2;
x1.func();
x2.func();
}

My questions ?
============

How does the c++ compiler organise the functions inside a class ?.

That depends on the compiler.

Are they stored as function pointers something like this
int (xx::func) () something the user cannot figure out and to him/her
it appears as object.member_function() e.g x1.func()

No. Usually, they are internally just implemented like nonmember functions
that get as a hidden extra parameter a pointer to the object they were
called for (the 'this' pointer).

While we were discussing all this some one told me that x1.func()
actually resolves to x1.func(*this)

Still another guy was of the opinion that x1.func() resolves to
x.func(&x1).

Basically, out of

struct X
{
void foo() { i = 5;}
int i;
};

int main()
{
X x;
x.foo();
}

the compiler makes something like:

struct X
{
int i;
}

void __X_foo(X* this)
{
this->i = 5;
}

int main()
{
X x;
__X_foo(x);
}

>
All this provides different thoughts and different interpretations

Please provide some clarity on how the compiler would actually organise
it

Why does it matter?

[Victor Bazarov]

Rolf Magnus wrote:

Ranjay wrote:

>Hi Everyone,
[...]
Please provide some clarity on how the compiler would actually
organise it

Why does it matter?

Hey, he wants to know, why should we care why he wants to know?

Ranjay, get yourself a copy of "Inside the C++ Object Model".

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Rolf Magnus]

Victor Bazarov wrote:

Rolf Magnus wrote:

>Ranjay wrote:

>>Hi Everyone,
[...]
Please provide some clarity on how the compiler would actually
organise it

Why does it matter?

Hey, he wants to know, why should we care why he wants to know?

Well, I want to know why he wants to know. Anything wrong with that?

[Victor Bazarov]

Rolf Magnus wrote:

Victor Bazarov wrote:

>Rolf Magnus wrote:

>>Ranjay wrote:
Hi Everyone,
[...]
Please provide some clarity on how the compiler would actually
organise it

Why does it matter?

Hey, he wants to know, why should we care why he wants to know?

Well, I want to know why he wants to know. Anything wrong with that?

Nothing, unless it's intended as a put-off, or as a rhetorical question
meaning "you don't need to know".

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Rolf Magnus]

Victor Bazarov wrote:

Rolf Magnus wrote:

>Victor Bazarov wrote:

>>Rolf Magnus wrote:
Ranjay wrote:
Hi Everyone,
[...]
Please provide some clarity on how the compiler would actually
organise it

Why does it matter?

Hey, he wants to know, why should we care why he wants to know?

Well, I want to know why he wants to know. Anything wrong with that?

Nothing, unless it's intended as a put-off, or as a rhetorical question
meaning "you don't need to know".

In that case, I wouldn't have answered the OP's question first.

[peter koch]

Rolf Magnus wrote:

Ranjay wrote:

[snip]

How does the c++ compiler organise the functions inside a class ?.

That depends on the compiler.

Are they stored as function pointers something like this
int (xx::func) () something the user cannot figure out and to him/her
it appears as object.member_function() e.g x1.func()

No. Usually, they are internally just implemented like nonmember functions
that get as a hidden extra parameter a pointer to the object they were
called for (the 'this' pointer).

[snip]

All this provides different thoughts and different interpretations

Please provide some clarity on how the compiler would actually organise
it

Why does it matter?

Well.... if the original poster thought that every member function took
up space in each object defined, he (and the rest of us!) would have a
very good reason to avoid member functions.

I had a collegue once who suffered from this misconception - and he
avoided memberfunctions like the plague, with a not so nice result. (He
was an old C-programmer so it did surprise me somewhat that he could
believe so), so even if that thought could look silly at first let's
not judge to hastily.

/Peter

[Victor Bazarov]

Rolf Magnus wrote:

Victor Bazarov wrote:

>Rolf Magnus wrote:

>>Victor Bazarov wrote:

Rolf Magnus wrote:
Ranjay wrote:
>Hi Everyone,
>[...]
>Please provide some clarity on how the compiler would actually
>organise it
>
Why does it matter?

Hey, he wants to know, why should we care why he wants to know?

Well, I want to know why he wants to know. Anything wrong with that?

Nothing, unless it's intended as a put-off, or as a rhetorical
question meaning "you don't need to know".

In that case, I wouldn't have answered the OP's question first.

Good defensive move! Nobody should suspect nothin'. "Here is the
answer, but why in hell do you think you need to know?" Give him
the candy and then slap him, just so the life didn't seem too sweet.

Ah, forget it, my coffee hasn't kicked in yet, probably.

[Michal Nazarewicz]

"Ranjay" <ra******@gmail.comwrites:

Are they stored as function pointers something like this
int (xx::func) () something the user cannot figure out and to him/her
it appears as object.member_function() e.g x1.func()

That's more or less how virtual methods work. Even though still
I suppose that instead of holding a pointer to each virtual method the
compiler puts a single pointer to a structure with pointers to virtual
methods (and each class has it's own such structure), so if you call
foo.virtualMethod() you are really calling something like
foo._virtual_methods->virtualMthod(&foo) where _virtual_methods points
to some magical structure _Foo_virtual_methods with all the pointers.

It of course may work differently plus it probably gets more
complicated when multiple inheritance comes in place.

--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>--<jid:mina86*jabber.org>--ooO--(_)--Ooo--