dev-cpp-users — Dev-C++ users discussion list

[Dev-C++] Choosing a Database for Win32 API

[Napoleon A. <n_a...@ya...>]

hello,
I've come to the point where I feel ready to learn how to write Win32
api programs that access databases. I have access on my system but my
orientation is towards MySql. 

My question is which database is easy to learn with win32 api and
mingw. By easy I mean availability of help and resouces and
downloadable add-ons for dev-cpp and mingw.

 I'll also appreciate URLs to the websites where i can download the
add-ons for dev-cpp and mingw.

Thanks.

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

Re: [Dev-C++] Difference between endl and "\n"

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

'\n' is a built in c++ escape sequece and is usable anywhere in the code,
endl depends on another header file.

Re: [Dev-C++] Difference between endl and "\n"

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

-------Original Message-------=0D
 =0D
From: Andre Macario Barros=0D
Date: =D4=E5=F4=DC=F1=F4=E7, 19 =D6=E5=E2=F1=EF=F5=DC=F1=E9=EF=F2 2003 5:=
20:04 =F0=EC=0D
To: dev...@li...=0D
Subject: [Dev-C++] Difference between endl and "\n"=0D
 =0D
   1. What is the difference between =0D
   cout << endl;=0D
   and=0D
   cout << "\n";=0D
   2. When I must use one and another?=0D
 =0D
 =0D
=3D=3D> std::endl also flushes the stream.=0D
 =0D
 =0D
Ioannis Vranos=0D
 =0D
* Programming pages: http://www.noicys.freeurl.com=0D
* Alternative URL: http://run.to/noicys=20

[Dev-C++] Difference between endl and "\n"

[Andre M. B. <ama...@uo...>]

   1. What is the difference between=20
   cout << endl;
   and
   cout << "\n";
   2. When I must use one and another?

Regards
Andre

Re: [Dev-C++] Problems with pointers to member functions

[Tulius L. <tul...@ho...>]

Per,


      You were right!
      I just appended a

         } else {
           action = &Sprite::stop;
         }

      and the thing worked.

      Excuse me while I'll put my diploma through the shredder.

      Thanks for you help!

      Tulius



>From: Per Westermark <pw...@ia...>
>To: Tulius Lima <tul...@ho...>
>CC: wo...@Ne...,  <dev...@li...>
>Subject: Re: [Dev-C++] Problems with pointers to member functions
>Date: Wed, 19 Feb 2003 00:31:24 +0100 (CET)
>
>See below.
>
>EMA System        email: pw...@ia...
>Per Westermark    web: http://iapetus.neab.net
>Vargvaegen 174B   phone: +46 8 410 17 198
>S-906 42 Umeaa
>Sweden
>
>
>On Tue, 18 Feb 2003, Tulius Lima wrote:
>
> > Hi Folks,
> >
> >
> >       I've been trying to work with pointers to member functions (after 
>I
> > saw the code posted by Japp de Wolff) to implement a finite-state 
>machine
> > for a SDL sprite engine.
> >
> >       After a few bumps I managed to compile the code. But it crashes 
>when
> > it runs (when it hits the member function).
> >
> >       Can anyone tell me please what's wrong with my code?
> >
> >
> >       TIA
> >       Tulius Lima
> >
> > ------------
> >
> > typedef void (Sprite::*Action)();
> >
> > class Sprite
> > {
> > public:
> >
> >   // operations
> >   void moveUp();
> >   void moveDown();
> >   void moveLeft();
> >   void moveRight();
> >   void stop();
> >   void move();
> >
> > };
> >
> >
> > int main(int argc, char *argv[])
> > {
> >   Sprite ship;
> >   Action action;
> >   Uint8* keys;
> >
> >   // SDL code omitted
> >
> >   int done = 0;
> >   while (!done)
> >   {
> >     keys = SDL_GetKeyState(NULL);
> >     if ( keys[SDLK_UP] )
> >     {
> >       action = &Sprite::moveUp;
> >     }
> >     if ( keys[SDLK_DOWN] )
> >     {
> >       action = &Sprite::moveDown;
> >     }
> >     if ( keys[SDLK_LEFT] )
> >     {
> >       action = &Sprite::moveLeft;
> >     }
> >     if ( keys[SDLK_RIGHT] )
> >     {
> >       action = &Sprite::moveRight;
> >     }
>
>And what will action be initialized to if none of the four if statements
>above are valid?
>
> >
> >     (ship.*action)(); // <--- problematic code
> >
> >     SDL_Flip(screen);
> >   }
> >
> >   // SDL finalization code omitted
> >
> >   return 0;
> > }
> > -------------------- end
> >
> > _________________________________________________________________
> > MSN Hotmail, o maior webmail do Brasil.  http://www.hotmail.com
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Dev-cpp-users mailing list
> > Dev...@li...
> > TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> > https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> >
>


_________________________________________________________________
MSN Hotmail, o maior webmail do Brasil.  http://www.hotmail.com

Re: [Dev-C++] Problems with pointers to member functions

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

See below.

EMA System        email: pw...@ia...
Per Westermark    web: http://iapetus.neab.net
Vargvaegen 174B   phone: +46 8 410 17 198
S-906 42 Umeaa
Sweden


On Tue, 18 Feb 2003, Tulius Lima wrote:

> Hi Folks,
>
>
>       I've been trying to work with pointers to member functions (after I
> saw the code posted by Japp de Wolff) to implement a finite-state machine
> for a SDL sprite engine.
>
>       After a few bumps I managed to compile the code. But it crashes when
> it runs (when it hits the member function).
>
>       Can anyone tell me please what's wrong with my code?
>
>
>       TIA
>       Tulius Lima
>
> ------------
>
> typedef void (Sprite::*Action)();
>
> class Sprite
> {
> public:
>
>   // operations
>   void moveUp();
>   void moveDown();
>   void moveLeft();
>   void moveRight();
>   void stop();
>   void move();
>
> };
>
>
> int main(int argc, char *argv[])
> {
>   Sprite ship;
>   Action action;
>   Uint8* keys;
>
>   // SDL code omitted
>
>   int done = 0;
>   while (!done)
>   {
>     keys = SDL_GetKeyState(NULL);
>     if ( keys[SDLK_UP] )
>     {
>       action = &Sprite::moveUp;
>     }
>     if ( keys[SDLK_DOWN] )
>     {
>       action = &Sprite::moveDown;
>     }
>     if ( keys[SDLK_LEFT] )
>     {
>       action = &Sprite::moveLeft;
>     }
>     if ( keys[SDLK_RIGHT] )
>     {
>       action = &Sprite::moveRight;
>     }

And what will action be initialized to if none of the four if statements
above are valid?

>
>     (ship.*action)(); // <--- problematic code
>
>     SDL_Flip(screen);
>   }
>
>   // SDL finalization code omitted
>
>   return 0;
> }
> -------------------- end
>
> _________________________________________________________________
> MSN Hotmail, o maior webmail do Brasil.  http://www.hotmail.com
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

[Dev-C++] Problems with pointers to member functions

[Tulius L. <tul...@ho...>]

Hi Folks,


      I've been trying to work with pointers to member functions (after I 
saw the code posted by Japp de Wolff) to implement a finite-state machine 
for a SDL sprite engine.

      After a few bumps I managed to compile the code. But it crashes when 
it runs (when it hits the member function).

      Can anyone tell me please what's wrong with my code?


      TIA
      Tulius Lima

------------

typedef void (Sprite::*Action)();

class Sprite
{
public:

  // operations
  void moveUp();
  void moveDown();
  void moveLeft();
  void moveRight();
  void stop();
  void move();

};


int main(int argc, char *argv[])
{
  Sprite ship;
  Action action;
  Uint8* keys;

  // SDL code omitted

  int done = 0;
  while (!done)
  {
    keys = SDL_GetKeyState(NULL);
    if ( keys[SDLK_UP] )
    {
      action = &Sprite::moveUp;
    }
    if ( keys[SDLK_DOWN] )
    {
      action = &Sprite::moveDown;
    }
    if ( keys[SDLK_LEFT] )
    {
      action = &Sprite::moveLeft;
    }
    if ( keys[SDLK_RIGHT] )
    {
      action = &Sprite::moveRight;
    }

    (ship.*action)(); // <--- problematic code

    SDL_Flip(screen);
  }

  // SDL finalization code omitted

  return 0;
}
-------------------- end

_________________________________________________________________
MSN Hotmail, o maior webmail do Brasil.  http://www.hotmail.com

[Dev-C++] system verses cin

[Samuel K. <ib...@ly...>]

One important cosideration: if you have to port your code to another OS avoid system. It is definite (unless some weird concidence occured) that you will have to change your system calls to fit the new operating system AND it isn't definite that the new OS has a function that does the same thing in the original OS. Portability is very important. If you do have to program for multiply operating systems you do not want to give yourself more work than necassary.


_____________________________________________________________
Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year.
http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus

[Dev-C++] GNU unshar() code

[Louis G. <lg...@ya...>]

Greets List,

I'm trying to get a copy of the source code for the GNU unshar() program
that compiles under DevC++. Any help would be appreciated. 

The code for unshar()  GNU on the  GNU website generates too many compiler
errors in DevC++ 4.9.6.0 

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

Re[3]: [Dev-C++] tarlib (Tar manipulation library)

[va13ak <va...@uk...>]

PW> Mostly gcc.

PW> /Per W


linux/unix gcc or win32 port of it ?

-- 
Best regards,
 va13ak                            mailto:va...@uk...

[Dev-C++] Problems saving files

[Lars-Bo J. <la...@fo...>]

Just upgraded to version 4.9.7.6.
Trying to start a new console project, I inserted a new file to the =
project
and tried to save it as a header file. Dev-C++ rsponds with an error =
saying

Cannot save file %s "M:\code\21days\day6\6-5\rect.h

the file is not saved but the tabs i9n the editor windows are renamed. =
Doing
a save all saves the files.

I have not experienced this before so I do not knoe if this is a bug or =
I=B4m
suddenly  just doing something wrong=20

Regards=20

Lars-Bo

Re[2]: Fwd: Re[2]: [Dev-C++] tarlib (Tar manipulation library)

[va13ak <va...@uk...>]

Hello Per,

PW> Is tarlib same as libtar?

PW> /Per W

Sorry for mistyping, when I typed 'tarlib' - I mean 'libtar'.
Sorry, again.

-- 
Best regards,
 va13ak                            mailto:va...@uk...

Re: Fwd: Re[2]: [Dev-C++] tarlib (Tar manipulation library)

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

Is tarlib same as libtar?

/Per W

On Tue, 18 Feb 2003, va13ak wrote:

> I mean, tarlib needed some header files (that not included to Dev-Cpp
> distribution). So I can't compile it.
>
> your suggestions ?
>
>
> Best regards,
>  va13ak                            mailto:va...@uk...
>
>

Re[2]: [Dev-C++] tarlib (Tar manipulation library)

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

Mostly gcc.

/Per W

On Tue, 18 Feb 2003, va13ak wrote:

> Hello, Per.
>
> You wrote
>
> PW> I have been using libtar in a number of projects, with quite good res=
ults.
> PW> I can't really say about system and/or compiler dependencies. On my t=
arget
> PW> machines, the code has built and worked ok.
>
> PW> /Per W
>
> Sorry for a stupid question, but what c compiler(s) you are(were) used
> ?
>
> --
> =D1 =F3=E2=E0=E6=E5=ED=E8=E5=EC,
>  va13ak                          mailto:va...@uk...
>
>

Fwd: Re[2]: [Dev-C++] tarlib (Tar manipulation library)

[va13ak <va...@uk...>]

I mean, tarlib needed some header files (that not included to Dev-Cpp
distribution). So I can't compile it.

your suggestions ?


Best regards,
 va13ak                            mailto:va...@uk...

Re[2]: [Dev-C++] tarlib (Tar manipulation library)

[va13ak <va...@uk...>]

Hello, Per.

You wrote

PW> I have been using libtar in a number of projects, with quite good res=
ults.
PW> I can't really say about system and/or compiler dependencies. On my t=
arget
PW> machines, the code has built and worked ok.

PW> /Per W

Sorry for a stupid question, but what c compiler(s) you are(were) used
?

--=20
=D1 =F3=E2=E0=E6=E5=ED=E8=E5=EC,
 va13ak                          mailto:va...@uk...

Re: [Dev-C++] tarlib (Tar manipulation library)

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

I have been using libtar in a number of projects, with quite good results.
I can't really say about system and/or compiler dependencies. On my target
machines, the code has built and worked ok.

/Per W

On Tue, 18 Feb 2003, va13ak wrote:

> Hello dev-cpp-users,
>
>   Tar manipulation library
>
>   Does anybody know where I can find the subj with no system and/or
>   compiler dependencies.
>
>   Thanks in advance.
>
> --
> Best regards,
>  va13ak                          mailto:va...@uk...
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

[Dev-C++] PE-File

[Christian W. <Chr...@vo...>]

Hi List,

I try to play around with the PE file format and can't get it running ...

What is lpFile for a type ???

To what should i cast it, so that it works ?

My last Test was:

 lpFile = fopen(...);



(The MSDN doesn't help much...)



Here the stuff from the MSDN:

/* DOS header identifies the NT PEFile signature dword
   the PEFILE header exists just after that dword	       */

#define PEFHDROFFSET(a) ((LPVOID)((BYTE *)a		     +	\
			 ((PIMAGE_DOS_HEADER)a)->e_lfanew    +	\
			 SIZE_OF_NT_SIGNATURE))


LPVOID lpFile;

int n = ((int)((PIMAGE_FILE_HEADER)PEFHDROFFSET
(lpFile))->NumberOfSections);



Here the declaration from WinNT.h:

//
// File header format.
//

typedef struct _IMAGE_FILE_HEADER 
{
    WORD    Machine;
    WORD    NumberOfSections;
    DWORD   TimeDateStamp;
    DWORD   PointerToSymbolTable;
    DWORD   NumberOfSymbols;
    WORD    SizeOfOptionalHeader;
    WORD    Characteristics;
} IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER;

[Dev-C++] tarlib (Tar manipulation library)

[va13ak <va...@uk...>]

Hello dev-cpp-users,

  Tar manipulation library

  Does anybody know where I can find the subj with no system and/or
  compiler dependencies.

  Thanks in advance.

-- 
Best regards,
 va13ak                          mailto:va...@uk...

Re: [Dev-C++] unicode

[Torsten C. <tc...@df...>]

<snip/>

> ==> At first i must say that there is no such thing as string<wchar_t> 
> since string is
>  
> typedef basic_string<char> string;
>  
> In some implementation char can be the same as wchar_t (switch or not it 
> doesn't matter). But since you can use wchar_t explicitly why use 
> switches? Keep in mind that the type wstring exists!

Well, IIRC it was commented out in my copy (strange)

Anyway - the problem is that I need *ALL* types in my application.

So now I have:

string - ANSI
tstring - ANSI/UNICODE depending on the switch
wstring - UNICODE
--
Torsten

Re: [Dev-C++] unicode

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

a-------Original Message-------=0D
 =0D
From: Torsten Curdt=0D
Date: =D4=F1=DF=F4=E7, 18 =D6=E5=E2=F1=EF=F5=DC=F1=E9=EF=F2 2003 1:02:29 =
=EC=EC=0D
To: dev...@li...=0D
Subject: Re: [Dev-C++] unicode=0D
 =0D
Jaap de Wolff wrote:=0D
> at this moment there is no std::string<wchar_t> support in the Mingw=0D
> compiler.=0D
> This is a known problem, it has to do with missing functions in MSVCRT.=
DLL
=0D
=0D
Ah... thanks for the feedback!=0D
=0D
But I did some changes in the include files and now have=0D
unicode working :)=0D
=0D
Do you know what functions are supposed to be missing?=0D
At least the basic string template works fine for me now.=0D
=0D
=0D
=3D=3D> At first i must say that there is no such thing as string<wchar_t=
> since
string is=0D
=0D
typedef basic_string<char> string;=0D
=0D
In some implementation char can be the same as wchar_t (switch or not it
doesn't matter). But since you can use wchar_t explicitly why use switche=
s?
Keep in mind that the type wstring exists!=0D
=0D
And as the standard nicely says:=0D
=0D
"[lib.string.classes] 21.2 String classes=0D
1 The header <string> defines a basic string class template and its trait=
s
that can handle all char-like (clause 21) template arguments with several
function signatures for manipulating varying length sequences of char-lik=
e
objects.=0D
2 The header <string> also defines two specific template classes string a=
nd
wstring and their special traits."=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++] unicode

[Torsten C. <tc...@df...>]

Jaap de Wolff wrote:
> at this moment there is no std::string<wchar_t> support in the Mingw
> compiler.
> This is a known problem, it has to do with missing functions in MSVCRT.DLL.

Ah... thanks for the feedback!

But I did some changes in the include files and now have
unicode working :)

Do you know what functions are supposed to be missing?
At least the basic string template works fine for me now.
--
Torsten

[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()

[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

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