[Dev-C++] Member functions vs regular functions

[Ioannis V. <no...@ho...>]

Reposting fixed.=0D
=0D
 =0D
-------Original Message-------=0D
 =0D
From: Ioannis Vranos=0D
Date: =D4=F1=DF=F4=E7, 18 =D6=E5=E2=F1=EF=F5=DC=F1=E9=EF=F2 2003 12:14:10=
 =EC=EC=0D
To: Dev-C++ Mailing List=0D
Subject: Re: [Dev-C++] differnece between system pause and cin.get()=0D
 =0D
-------Original Message-------=0D
 =0D
From: Per Westermark=0D
Date: =D4=F1=DF=F4=E7, 18 =D6=E5=E2=F1=EF=F5=DC=F1=E9=EF=F2 2003 11:32:15=
 =F0=EC=0D
To: Ioannis Vranos=0D
Cc: Dev-C++ Mailing List=0D
Subject: Re: [Dev-C++] differnece between system pause and cin.get()=0D
 =0D
=0D
1 - You may not assume that the this ptr is always sent in registers.=0D
Depending on compiler and compiler options, it might always be sent on=0D
stack as a regular but hidden parameter.=0D
=0D
 =0D
=0D
=3D=3D> In fact we cannot assume anything. Everything can be inlined by t=
he
compiler and no *ptr to be used. Compiler vendors can be as smart as they
want.=0D
 =0D
 =0D
=0D
2 - Regular function calls doesn't have a this ptr, so no time used to=0D
send a this ptr. Member function always have this ptr, so depending on=0D
calling convention, time is needed on all calls, or on only the first=0D
obj->member() but not when member() calls member2().=0D
 =0D
 =0D
=3D=3D> How non-member friend functions really access a member x of an ob=
ject y
in reality? Probably through the *ptr.=0D
 =0D
 =0D
=0D
=0D
> Member functions always have a regular address. Your description of cal=
l=0D
> through an offset in an array is the special case of a call to a virtua=
l=0D
> method.=0D
=0D
=0D
=0D
=3D=3D> Try assign the "address" of a member function to a void *. Or bet=
ter
provide us with code that prints the "address" of a member function.=0D
 =0D
 =0D
 =0D
This is just a protection the C++ compiler adds, since a normal pointer=0D
call would not know about a this ptr. If you program from assember - or i=
f=0D
you know the full decorated name of the member function, you may still=0D
have a pointer directly to the method and call it directly. But then Your=
=0D
code most manually make sure that the hidden 'this' parameter is sent=0D
accurding to current calling convention.=0D
=0D
=0D
 =0D
=3D=3D> This is nonsense. Every memory address can be assigned to a void =
*. If
member functions had a regular memory address, not being able to assign i=
t
to void * would break the language. Not to mention the fact that we canno=
t
print its "address". Not even with printf("%p").=0D
 =0D
=3D=3D> The address of a member function can be implemented with whatever=
 way
the implementors like. One can use your style with a regular function
passing a *this. Another can use an array offset like the VTable. Another
something else he wants not to talk about.=0D
=0D
=3D=3D> Member functions is not guaranteed to be the same as non-member
functions, in fact it is assumed they are not.=0D
 =0D
 =0D
 =0D
I already mentioned the case below in the previous mail, i.e. code qualit=
y=0D
of regular C-style call with a manual THIS ptr is often a bit slower due=0D
to less optimization in compiler. The important thing is that a regular=0D
function most of the time doesn't NEED the THIS ptr, while all non-static=
=0D
member fuctions MUST have it.=0D
 =0D
=3D=3D> But above you said that a friend function does not use *this poin=
ter
when the object is passed as an argument (reference or whatever).=0D
 =0D
=3D=3D> A regular function not using an object's facilities naturally doe=
sn't
use its *this pointer. But this is common sense, right?=0D
 =0D
=0D
=0D
> #include <iostream>=0D
> #include <ctime>=0D
> #include <limits>=0D
> #include <cstdio>=0D
// ...=0D
>=0D
>=0D
> =3D=3D> This code in my system produces:=0D
>=0D
> C:\c>temp=0D
> Number of iterations for each kind: 214748364=0D
> Time consumed by 214748364 calls of void something::test(): 0.45=0D
> Time consumed by 214748364 calls of void testf(something &): 0.461=0D
>=0D
>=0D
> The difference is very slight, negligible. However after repeative runs=
,=0D
> testf() consistently remains the slower:=0D
>=0D
> C:\c>temp=0D
> Number of iterations for each kind: 214748364=0D
> Time consumed by 214748364 calls of void something::test(): 0.45=0D
> Time consumed by 214748364 calls of void testf(something &): 0.461=0D
>=0D
> C:\c>temp=0D
> Number of iterations for each kind: 214748364=0D
> Time consumed by 214748364 calls of void something::test(): 0.45=0D
> Time consumed by 214748364 calls of void testf(something &): 0.481=0D
>=0D
> C:\c>temp=0D
> Number of iterations for each kind: 214748364=0D
> Time consumed by 214748364 calls of void something::test(): 0.45=0D
> Time consumed by 214748364 calls of void testf(something &): 0.481=0D
>=0D
> C:\c>temp=0D
> Number of iterations for each kind: 214748364=0D
> Time consumed by 214748364 calls of void something::test(): 0.45=0D
> Time consumed by 214748364 calls of void testf(something &): 0.481=0D
>=0D
>=0D
>=0D
>=0D
> Bottom line: As I said on my original mail, member calls are slower tha=
n=0D
> regular calls, but these extra nanoseconds might be ignored for just ab=
out=0D
> all programs out there, since the majority of the runtime is in other=0D
> parts of the program.=0D
=0D
=0D
 =0D
=3D=3D> Bottom line is that i provided you with code which proves that us=
ually
the opposite happens (but with ++very negligible difference).=0D
 =0D
 =0D
 =0D
Ioannis Vranos=0D
=0D
* Programming pages: http://www.noicys.freeurl.com=0D
* Alternative URL: http://run.to/noicys=20