dev-cpp-users

[Dev-C++] differnece between system pause and cin.get()

[Catsquotl <C.a...@hc...>]

Hello,

Obviously there are quite a lot of differences between the two.
However since I am new to c++ and pragramming all together i was wondering 
why cin.get()
works sometimes to pauze the system after a programm and sometimes it won`t.

It seems to me that cin.get() before return 0;
would use less memory than system pause.

greets Catsquotl

Re: [Dev-C++] differnece between system pause and cin.get()

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

-------Original Message-------=0D
 =0D
From: Catsquotl=0D
Date: =C4=E5=F5=F4=DD=F1=E1, 17 =D6=E5=E2=F1=EF=F5=DC=F1=E9=EF=F2 2003 2:=
21:19 =EC=EC=0D
To: dev...@li...=0D
Subject: [Dev-C++] differnece between system pause and cin.get()=0D
 =0D
Hello,=0D
=0D
Obviously there are quite a lot of differences between the two.=0D
However since I am new to c++ and pragramming all together i was wonderin=
g =0D
why cin.get()=0D
works sometimes to pauze the system after a programm and sometimes it won=
`t.=0D
=0D
=3D=3D> Because one or more '\n' has remain in the stream from previous c=
in
use(s).=0D
=0D
=0D
It seems to me that cin.get() before return 0;=0D
would use less memory than system pause.=0D
=0D
=3D=3D> It depends on how many things are written inside get(). However t=
he
member function call is usually faster than a regular function call. But =
i
do not think you should be so space/time concerned. :)=0D
=0D
=0D
Ioannis Vranos=0D
=0D
* Programming pages: http://www.noicys.freeurl.com=0D
* Alternative URL: http://run.to/noicys=20

Re: [Dev-C++] differnece between system pause and cin.get()

[Per W. <pw...@ia...>]

On Tue, 18 Feb 2003, Ioannis Vranos wrote:

> -------Original Message-------
>
> From: Catsquotl
> Date: =C4=E5=F5=F4=DD=F1=E1, 17 =D6=E5=E2=F1=EF=F5=DC=F1=E9=EF=F2 2003 2:=
21:19 =EC=EC
> To: dev...@li...
> Subject: [Dev-C++] differnece between system pause and cin.get()
>
> Hello,
>
> Obviously there are quite a lot of differences between the two.
> However since I am new to c++ and pragramming all together i was wonderin=
g
> why cin.get()
> works sometimes to pauze the system after a programm and sometimes it won=
`t.
>
> =3D=3D> Because one or more '\n' has remain in the stream from previous c=
in
> use(s).
>
>
> It seems to me that cin.get() before return 0;
> would use less memory than system pause.
>
> =3D=3D> It depends on how many things are written inside get(). However t=
he
> member function call is usually faster than a regular function call. But =
i
> do not think you should be so space/time concerned. :)

For just about any type of programming, you may ignore any speed
difference between member call and regular function call. For a new
normal PC, we are talking nano-seconds. A member function call is normally
just a teeny bit slower, since it is a regular call with the extra
requirement that it must send a 'this' pointer in registers or on the
stack. If the member function is virtual, the member call must also
perform the call indirect, by locating the call address in the VMT
for the object. The only time a member call is as fast as a regular
function call is if the member function is declared static - but then it
is a regular function declared in the namespace of the class.

What is important in this case is that system() is special. It is a
request to start a new program 'PAUSE' and wait for that program to end,
i.e. wait until you press a character.

This is not the slightest problem for testing a debug-version of a
program. However, in real production code, some care should be taken about
the use of system() calls, because of the very large amount of work the os
has to do to perform the call. One call to system() might sound nice, but
probably represents 100-10000 calls or more depending on what type of
command that are put as argument. The OS has to start a new proces, with
new stack... and might in some cases consume more memory and/or cpu
time for the system() call than for the rest of the application.

/Per W

>
> Ioannis Vranos
>
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL: http://run.to/noicys

Re: [Dev-C++] differnece between system pause and cin.get()

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

-------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 2:16:24 =
=F0=EC=0D
To: Ioannis Vranos=0D
Cc: dev...@li...=0D
Subject: Re: [Dev-C++] differnece between system pause and cin.get()=0D
 =0D
> =3D=3D> It depends on how many things are written inside get(). However=
 the=0D
> member function call is usually faster than a regular function call. Bu=
t i=0D
> do not think you should be so space/time concerned. :)=0D
=0D
For just about any type of programming, you may ignore any speed=0D
difference between member call and regular function call. For a new=0D
normal PC, we are talking nano-seconds. A member function call is normall=
y=0D
just a teeny bit slower, since it is a regular call with the extra=0D
requirement that it must send a 'this' pointer in registers or on the=0D
stack. If the member function is virtual, the member call must also=0D
perform the call indirect, by locating the call address in the VMT=0D
for the object. The only time a member call is as fast as a regular=0D
function call is if the member function is declared static - but then it=0D
is a regular function declared in the namespace of the class.=0D
=0D
-------------------------------------------------------------------------=
----
------------=0D
=3D=3D> We are getting lost in the details here, but for non-virtual memb=
er
functions passing *this does not imply any additional time cost in
comparison to regular functions. Also i do not think passing *this to
anything is required. Member functions do not have a regular address. The=
y
are usually called as an offset in an array. It is something like=0D
=0D
array[4](whatever)=0D
=0D
=0D
A regular friend function call for example would be implemented as someth=
ing
like:=0D
=0D
something(this, whatever). It's tough to say which is faster. So lets
consider them as of equal time cost and be in peace. :P=0D
=0D
However statistically speaking member functions tend to be small and inli=
ned
 while regular functions manipulating objects not. But this can be disput=
ed
too. As i said, this shouldn't be taken under any consideration, that is =
the
time cost difference between cin.get() and system("pause"). Although syst=
em
has a function call time cost+a program invocation time cost+command.com/=
cmd
exe invocation time cost.=0D
-------------------------------------------------------------------------=
----
----------------=0D
=0D
=0D
=0D
What is important in this case is that system() is special. It is a=0D
request to start a new program 'PAUSE' and wait for that program to end,=0D
i.e. wait until you press a character.=0D
=0D
This is not the slightest problem for testing a debug-version of a=0D
program. However, in real production code, some care should be taken abou=
t=0D
the use of system() calls, because of the very large amount of work the o=
s=0D
has to do to perform the call. One call to system() might sound nice, but=
=0D
probably represents 100-10000 calls or more depending on what type of=0D
command that are put as argument. The OS has to start a new proces, with=0D
new stack... and might in some cases consume more memory and/or cpu=0D
time for the system() call than for the rest of the application.=0D
=0D
=3D=3D> Yes.=0D
=0D
=0D
Ioannis Vranos=0D
=0D
* Programming pages: http://www.noicys.freeurl.com=0D
* Alternative URL: http://run.to/noicys=20

Re: [Dev-C++] differnece between system pause and cin.get()

[Per W. <pw...@ia...>]

On Tue, 18 Feb 2003, Ioannis Vranos wrote:

> -------Original Message-------
>
> From: Per Westermark
> Date: =D4=F1=DF=F4=E7, 18 =D6=E5=E2=F1=EF=F5=DC=F1=E9=EF=F2 2003 2:16:24 =
=F0=EC
> To: Ioannis Vranos
> Cc: dev...@li...
> Subject: Re: [Dev-C++] differnece between system pause and cin.get()
>
> > =3D=3D> It depends on how many things are written inside get(). However=
 the
> > member function call is usually faster than a regular function call. Bu=
t i
> > do not think you should be so space/time concerned. :)
>
> For just about any type of programming, you may ignore any speed
> difference between member call and regular function call. For a new
> normal PC, we are talking nano-seconds. A member function call is normall=
y
> just a teeny bit slower, since it is a regular call with the extra
> requirement that it must send a 'this' pointer in registers or on the
> stack. If the member function is virtual, the member call must also
> perform the call indirect, by locating the call address in the VMT
> for the object. The only time a member call is as fast as a regular
> function call is if the member function is declared static - but then it
> is a regular function declared in the namespace of the class.
>
> -------------------------------------------------------------------------=
----
> ------------
> =3D=3D> We are getting lost in the details here, but for non-virtual memb=
er
> functions passing *this does not imply any additional time cost in
> comparison to regular functions. Also i do not think passing *this to
> anything is required. Member functions do not have a regular address. The=
y
> are usually called as an offset in an array. It is something like

For register calling convention, the this pointer may be sent for free
from one member of the class to another member of the class, since the
register will already be initialized with this. For stack calling
convention, it HAS to take extra time, since it's an extra 32-bit put push
on the stack. Also, weith register calling, the first call HAVE to take
extra time, since the compiler must load the address of the object before
making the call.

The only time the compiler can avoid passing the this ptr at a method
call, is if the destination method is non-virtual and the compiler
generates the code inline. Even if it knows that a specific method never
touches any part of the object, the compiler may only ignore the this ptr
if it knows that ALL uses of the method will always use same calling
convention. If some modules just sees the declaration of the method wile
compile modules may see the full implementation, the compiler must be
consequent and assume that the method needs the this ptr. Static-declared
methods are the only way to inform the compiler that a method does not
have a this ptr. But then a static method is a regular function declared
in the namespace of the class.

Member functions always have a regular address. Your description of call
through an offset in an array is the special case of a call to a virtual
method. However, the constructor for the same class may still call
directly without going to the VMT (Virtual Method Table). A call through
the VMT is slower, since the compiler first have to load the VMT table
address as an offset from the this pointer, and then do the call from an
offset into the table.

If you don't believe me, just ask the compiler to emit assembler output
and have a peek.

>
> array[4](whatever)
>
>
> A regular friend function call for example would be implemented as someth=
ing
> like:
>
> something(this, whatever). It's tough to say which is faster. So lets
> consider them as of equal time cost and be in peace. :P
>
> However statistically speaking member functions tend to be small and inli=
ned
>  while regular functions manipulating objects not. But this can be disput=
ed
> too. As i said, this shouldn't be taken under any consideration, that is =
the
> time cost difference between cin.get() and system("pause"). Although syst=
em
> has a function call time cost+a program invocation time cost+command.com/=
cmd
> exe invocation time cost.
> -------------------------------------------------------------------------=
----
> ----------------

The information that may be seen from a couple of analyzes of different
compilers - several peopple have done it is:

A cpp+ compiler normally generantes more efficient code for a member call
with implicit this pointer, than the corresponding C code with an explicit
THIS ptr, i.e.

  obj->hello(a,b,c);

is normally faster than

  hello(&obj,a,b,c);

and a C++ call to a virtual method normally generates better code than a C
call through a pointer access, i.e.

  obj->my_virtual_call(a,b,c);

is normally faster than

  obj->vmt[3]->my_virtual_call(&obj,a,b,c);

But this is just that since a C++ compiler have somany this references and
VMT-indirect calls, the compiler writers have made sure that these cases
should generate good code, my making sure that the this ptr have a high
priority while assigning register variables etc. It still doesn't change
the fact that for stack parameter passing, the this ptr is extra work, and
a virtual method is always extra work compared to a non-virtual method or
compared to a regular function call.

Bottom line: As I said on my original mail, member calls are slower than
regular calls, but these extra nanoseconds might be ignored for just about
all programs out there, since the majority of the runtime is in other
parts of the program.

>
>
>
> What is important in this case is that system() is special. It is a
> request to start a new program 'PAUSE' and wait for that program to end,
> i.e. wait until you press a character.
>
> This is not the slightest problem for testing a debug-version of a
> program. However, in real production code, some care should be taken abou=
t
> the use of system() calls, because of the very large amount of work the o=
s
> has to do to perform the call. One call to system() might sound nice, but
> probably represents 100-10000 calls or more depending on what type of
> command that are put as argument. The OS has to start a new proces, with
> new stack... and might in some cases consume more memory and/or cpu
> time for the system() call than for the rest of the application.
>
> =3D=3D> Yes.
>
>
> Ioannis Vranos
>
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL: http://run.to/noicys

Re: [Dev-C++] differnece between system pause and cin.get()

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

-------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 9:42:16 =
=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
For register calling convention, the this pointer may be sent for free=0D
from one member of the class to another member of the class, since the=0D
register will already be initialized with this. For stack calling=0D
convention, it HAS to take extra time, since it's an extra 32-bit put pus=
h=0D
on the stack. Also, weith register calling, the first call HAVE to take=0D
extra time, since the compiler must load the address of the object before=
=0D
making the call.=0D
=0D
=0D
=3D=3D> Ok, so in few words you are telling that the regular function cal=
ls have
an additional extra cost because of the stack calling convention, while
member functions have that time cost only at the first call when it fetch=
es
it from memory to register. So we agree.=0D
=0D
=0D
=0D
Member functions always have a regular address. Your description of call=0D
through an offset in an array is the special case of a call to a virtual=0D
method.=0D
=0D
=0D
=3D=3D> No, no, no. Try assigning a member function to a pointer for a re=
gular
function. Try to print the "address" of a member function. The standard d=
oes
not restrict how member functions are implemented, only that they cannot =
be
expected to be regular functions. Usually, member functions are called
through an offset of an array.=0D
=0D
=0D
 However, the constructor for the same class may still call=0D
directly without going to the VMT (Virtual Method Table). A call through=0D
the VMT is slower, since the compiler first have to load the VMT table=0D
address as an offset from the this pointer, and then do the call from an=0D
offset into the table.=0D
=0D
If you don't believe me, just ask the compiler to emit assembler output=0D
and have a peek.=0D
=0D
=0D
=3D=3D> You are out of range for me. :) I do not know assembly almost at =
all and
i am telling only what i have read/learned. But since we know C++ we can =
do
the test:=0D
=0D
#include <iostream>=0D
#include <ctime>=0D
#include <limits>=0D
#include <cstdio>=0D
=0D
class something=0D
{=0D
 unsigned long x;=0D
=0D
 public:=0D
 something(int y=3D0):x(y) {}=0D
=0D
 void test();=0D
 friend void testf(something &);=0D
};=0D
=0D
=0D
=0D
int main()=0D
{=0D
 using namespace std;=0D
=0D
 clock_t t1, t2, t3, t4, temp;=0D
=0D
 unsigned long i;=0D
 =0D
 something blade;=0D
 =0D
 cout<<"Number of iterations for each kind: "<<numeric_limits<unsigned
long>::max()/20<<endl;=0D
=0D
=0D
 for (t1=3Dtemp=3Dclock(); !(t1-temp); t1=3Dclock())=0D
   ;=0D
=0D
=0D
 for(i=3D0; i<numeric_limits<unsigned long>::max()/20; i++)=0D
    blade.test();=0D
    =0D
 t2=3Dclock();=0D
 =0D
 cout<<"Time consumed by "<<numeric_limits<unsigned long>::max()/20<<" ca=
lls
of void something::test(): ";=0D
 cout<<static_cast<double>(t2-t1)/CLOCKS_PER_SEC<<endl;=0D
 =0D
=0D
 for (t3=3Dtemp=3Dclock(); !(t3-temp); t3=3Dclock())=0D
   ;=0D
=0D
 for(i=3D0; i<numeric_limits<unsigned long>::max()/20; i++)=0D
    testf(blade);=0D
    =0D
 t4=3Dclock();=0D
 =0D
 cout<<"Time consumed by "<<numeric_limits<unsigned long>::max()/20<<" ca=
lls
of void testf(something &): ";=0D
 cout<<static_cast<double>(t4-t3)/CLOCKS_PER_SEC<<endl;=0D
=0D
}=0D
=0D
=0D
void testf(something &x) { x.x++; }=0D
=0D
void something::test() { x++; }=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,
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 than=0D
regular calls, but these extra nanoseconds might be ignored for just abou=
t=0D
all programs out there, since the majority of the runtime is in other=0D
parts of the program.=0D
=0D
=0D
=3D=3D> I disagree, but that's life.=0D
=0D
=0D
=0D
Ioannis Vranos=0D
=0D
* Programming pages: http://www.noicys.freeurl.com=0D
* Alternative URL: http://run.to/noicys=20

Re: [Dev-C++] differnece between system pause and cin.get()

[Per W. <pw...@ia...>]

On Tue, 18 Feb 2003, Ioannis Vranos wrote:

> -------Original Message-------
>
> From: Per Westermark
> Date: =D4=F1=DF=F4=E7, 18 =D6=E5=E2=F1=EF=F5=DC=F1=E9=EF=F2 2003 9:42:16 =
=F0=EC
> To: Ioannis Vranos
> Cc: Dev-C++ Mailing List
> Subject: Re: [Dev-C++] differnece between system pause and cin.get()
>
> For register calling convention, the this pointer may be sent for free
> from one member of the class to another member of the class, since the
> register will already be initialized with this. For stack calling
> convention, it HAS to take extra time, since it's an extra 32-bit put pus=
h
> on the stack. Also, with register calling, the first call HAVE to take
> extra time, since the compiler must load the address of the object before
> making the call.
>
>
> =3D=3D> Ok, so in few words you are telling that the regular function cal=
ls have
> an additional extra cost because of the stack calling convention, while
> member functions have that time cost only at the first call when it fetch=
es
> it from memory to register. So we agree.

1 - You may not assume that the this ptr is always sent in registers.
Depending on compiler and compiler options, it might always be sent on
stack as a regular but hidden parameter.

2 - Regular function calls doesn't have a this ptr, so no time used to
send a this ptr. Member function always have this ptr, so depending on
calling convention, time is needed on all calls, or on only the first
obj->member() but not when member() calls member2().

>
>
>
> Member functions always have a regular address. Your description of call
> through an offset in an array is the special case of a call to a virtual
> method.
>
>
> =3D=3D> No, no, no. Try assigning a member function to a pointer for a re=
gular
> function. Try to print the "address" of a member function. The standard d=
oes
> not restrict how member functions are implemented, only that they cannot =
be
> expected to be regular functions. Usually, member functions are called
> through an offset of an array.

This is just a protection the C++ compiler adds, since a normal pointer
call would not know about a this ptr. If you program from assember - or if
you know the full decorated name of the member function, you may still
have a pointer directly to the method and call it directly. But then Your
code most manually make sure that the hidden 'this' parameter is sent
accurding to current calling convention.

>
>
>  However, the constructor for the same class may still call
> directly without going to the VMT (Virtual Method Table). A call through
> the VMT is slower, since the compiler first have to load the VMT table
> address as an offset from the this pointer, and then do the call from an
> offset into the table.
>
> If you don't believe me, just ask the compiler to emit assembler output
> and have a peek.
>
>
> =3D=3D> You are out of range for me. :) I do not know assembly almost at =
all and
> i am telling only what i have read/learned. But since we know C++ we can =
do
> the test:

I already mentioned the case below in the previous mail, i.e. code quality
of regular C-style call with a manual THIS ptr is often a bit slower due
to less optimization in compiler. The important thing is that a regular
function most of the time doesn't NEED the THIS ptr, while all non-static
member fuctions MUST have it.

> #include <iostream>
> #include <ctime>
> #include <limits>
> #include <cstdio>
>
> class something
> {
>  unsigned long x;
>
>  public:
>  something(int y=3D0):x(y) {}
>
>  void test();
>  friend void testf(something &);
> };
>
>
>
> int main()
> {
>  using namespace std;
>
>  clock_t t1, t2, t3, t4, temp;
>
>  unsigned long i;
>
>  something blade;
>
>  cout<<"Number of iterations for each kind: "<<numeric_limits<unsigned
> long>::max()/20<<endl;
>
>
>  for (t1=3Dtemp=3Dclock(); !(t1-temp); t1=3Dclock())
>    ;
>
>
>  for(i=3D0; i<numeric_limits<unsigned long>::max()/20; i++)
>     blade.test();
>
>  t2=3Dclock();
>
>  cout<<"Time consumed by "<<numeric_limits<unsigned long>::max()/20<<" ca=
lls
> of void something::test(): ";
>  cout<<static_cast<double>(t2-t1)/CLOCKS_PER_SEC<<endl;
>
>
>  for (t3=3Dtemp=3Dclock(); !(t3-temp); t3=3Dclock())
>    ;
>
>  for(i=3D0; i<numeric_limits<unsigned long>::max()/20; i++)
>     testf(blade);
>
>  t4=3Dclock();
>
>  cout<<"Time consumed by "<<numeric_limits<unsigned long>::max()/20<<" ca=
lls
> of void testf(something &): ";
>  cout<<static_cast<double>(t4-t3)/CLOCKS_PER_SEC<<endl;
>
> }
>
>
> void testf(something &x) { x.x++; }
>
> void something::test() { x++; }
>
>
> =3D=3D> This code in my system produces:
>
> C:\c>temp
> Number of iterations for each kind: 214748364
> Time consumed by 214748364 calls of void something::test(): 0.45
> Time consumed by 214748364 calls of void testf(something &): 0.461
>
>
> The difference is very slight, negligible. However after repeative runs,
> testf() consistently remains the slower:
>
> C:\c>temp
> Number of iterations for each kind: 214748364
> Time consumed by 214748364 calls of void something::test(): 0.45
> Time consumed by 214748364 calls of void testf(something &): 0.461
>
> C:\c>temp
> Number of iterations for each kind: 214748364
> Time consumed by 214748364 calls of void something::test(): 0.45
> Time consumed by 214748364 calls of void testf(something &): 0.481
>
> C:\c>temp
> Number of iterations for each kind: 214748364
> Time consumed by 214748364 calls of void something::test(): 0.45
> Time consumed by 214748364 calls of void testf(something &): 0.481
>
> C:\c>temp
> Number of iterations for each kind: 214748364
> Time consumed by 214748364 calls of void something::test(): 0.45
> Time consumed by 214748364 calls of void testf(something &): 0.481
>
>
>
>
> Bottom line: As I said on my original mail, member calls are slower than
> regular calls, but these extra nanoseconds might be ignored for just abou=
t
> all programs out there, since the majority of the runtime is in other
> parts of the program.
>
>
> =3D=3D> I disagree, but that's life.
>
>
>
> Ioannis Vranos
>
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL: http://run.to/noicys

Re: [Dev-C++] differnece between system pause and cin.get()

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

-------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
=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
=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
this "address". Not even with printf("%p").=0D
 =0D
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
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
A regular function not using an object's facilities naturally doesn'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
=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

[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

Re: [Dev-C++] differnece between system pause and cin.get()

[Catsquotl <C.a...@hc...>]

At 00:24 18-2-2003 +0200, Ioannis Vranos wrote:
>-------Original Message-------
>
>From: <mailto:C.a...@hc...>Catsquotl
>Date: =C4=E5=F5=F4=DD=F1=E1, 17 =D6=E5=E2=F1=EF=F5=DC=F1=E9=EF=F2 2003=
 2:21:19 =EC=EC
>To:=20
><mailto:dev...@li...>dev...@li...=
.net
>Subject: [Dev-C++] differnece between system pause and cin.get()
>
>Hello,
>
>Obviously there are quite a lot of differences between the two.
>However since I am new to c++ and pragramming all together i was wondering
>why cin.get()
>works sometimes to pauze the system after a programm and sometimes it=
 won`t.
>=3D=3D> Because one or more '\n' has remain in the stream from previous cin=
=20
>use(s).
>
Thanks for the response.
Is there a way of chekking if there`s annything left in the cin stream.
Or to empty it for that matter before using it as a tool for keeping dos=20
boxes open :-)

greets Cat=20

Re: [Dev-C++] differnece between system pause and cin.get()

[Robson B. <rob...@su...>]

the function system() is a shortcut to use dos comands like system("ATTRIB")
or system("PAUSE"). cin.get() is a c++ function that you can adjust
settings. is more flexible. that was what i verified.

[]'s
  ----- Original Message -----
  From: Catsquotl
  To: dev...@li...
  Sent: Monday, February 17, 2003 8:21 PM
  Subject: Re: [Dev-C++] differnece between system pause and cin.get()


  At 00:24 18-2-2003 +0200, Ioannis Vranos wrote:

    -------Original Message-------

    From: Catsquotl
    Date: ÄåõôÝñá, 17 ÖåâñïõÜñéïò 2003 2:21:19 ìì
    To: dev...@li...
    Subject: [Dev-C++] differnece between system pause and cin.get()

    Hello,

    Obviously there are quite a lot of differences between the two.
    However since I am new to c++ and pragramming all together i was
wondering
    why cin.get()
    works sometimes to pauze the system after a programm and sometimes it
won`t.
    ==> Because one or more '\n' has remain in the stream from previous cin
use(s).

  Thanks for the response.
  Is there a way of chekking if there`s annything left in the cin stream.
  Or to empty it for that matter before using it as a tool for keeping dos
boxes open :-)

  greets Cat

Re: [Dev-C++] differnece between system pause and cin.get()

[Lucas K. T. <lk...@bo...>]

Although this is probably pretty useless to you...
=20
>Thanks for the response.
>Is there a way of chekking if there`s annything left in the >cin =
stream.=20
>Or to empty it for that matter before using it as a tool for >keeping =
dos boxes open :-)

Well to empty the keyboard buffer, you'd have to go through memory =
access and move the value that is within: 40h:[1Ch] to 40h:[1Ah], 'cause =
you see, the keyb buffer is circular and 32-bytes long, and 40h:[1Ah] =
points to it's head, while 40h:[1Ch] points to it's tail, so basically, =
by assigning the same value to them, the buffer would get cleared, =
sample code (although I'm not sure this would work in a Win console =
program, it'd work on a DOS program):

word tail;
tail =3D peek(0x40, 0x1C);
poke(0x40, 0x1A, tail);

Or perhaps you could try:
poke(0x40, 0x1A, peek(0x40, 0x1C));

directly... I'm have tested neithe,r but they should work just fine...

Unecessary information, thoguh... but it's always nice ot learn new =
things... hehee =3D)

lkt153

Re: [Dev-C++] differnece between system pause and cin.get()

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

-------Original Message-------=0D
 =0D
From: Catsquotl=0D
Date: =D4=F1=DF=F4=E7, 18 =D6=E5=E2=F1=EF=F5=DC=F1=E9=EF=F2 2003 1:22:44 =
=F0=EC=0D
To: dev...@li...=0D
Subject: Re: [Dev-C++] differnece between system pause and cin.get()=0D
 =0D
 Thanks for the response.=0D
Is there a way of chekking if there`s annything left in the cin stream. =0D
Or to empty it for that matter before using it as a tool for keeping dos
boxes open :-)=0D
=0D
=0D
=3D=3D> You can ensure it is empty by applying cin.ignore() after any cin=
 you
perform. There are other ways too.=0D
=0D
=0D
Ioannis Vranos=0D
=0D
* Programming pages: http://www.noicys.freeurl.com=0D
* Alternative URL: http://run.to/noicys=20