Something I've always wondered about (C++)

[gilly_54]

I'm using "Visual C++ 2008 Express Edition" for my compiling and stuff.
OS: Windows Vista
So I have a couple of questions.
1. I mostly code Win32 console applications, take this really simple bit of code for example:

#include "stdafx.h"
#include <iostream>

using namespace std;

int main(){
	int age;
	cout<<"Enter your age: ";
	cin>>age;
	cout<<"Your age is: "<<age<<endl;
	cin.get();
	cin.get();
}

Now back when I used Visual C++ 2005 Express, I don't recall having to put in cin.get(); twice for the console window to stay and show me a result. If I put it in once, it just opens and closes as soon as the program runs (which is a split second), its as if I'm not even putting in a cin.get();
I've seen people using return 0; and I've always wondered about it, I tried shoving it in a few times to no avail...
So, do I have to stick to two cin.get();'s? Or is there a simpler way that I probably have no clue of?

 

[seeker010]

there might be something wrong with the console wrapper in VC++ 2k8 express.

also, if a main() function is defined, it must return an int value in C++. the norm is to return 0.

just a side note: have you tried running your problem with ctrl+f5?

I just ran a quick test and it works fine in VS 2k8 Pro

#include <iostream>


#define WINDOWS_LEAN_AND_MEAN
#include <windows.h>
#include <tchar.h>

using namespace std;

int _tmain(int argc, _TCHAR* argv[])
{
	cout << "hello world!" << endl;
	return 0;
}

 

[gilly_54]

Ah now there's something new...Ctrl-F5
Seems to do the trick when I put in return 0; and hit ctrl-f5...HOWEVER:
Once I run the .exe outside the compiler, i.e. browse to my projects directory/release/program.exe it runs but doesn't prompt me "Press any key to continue" anymore, it just opens and closes once the program runs...
Now am I stuck to having to run the program from the compiler every time?

 

[seeker010]

Ah now there's something new...Ctrl-F5
Seems to do the trick when I put in return 0; and hit ctrl-f5...HOWEVER:
Once I run the .exe outside the compiler, i.e. browse to my projects directory/release/program.exe it runs but doesn't prompt me "Press any key to continue" anymore, it just opens and closes once the program runs...
Now am I stuck to having to run the program from the compiler every time?

when you run it in the IDE, it runs your program in a console wrapper, which prompts you to terminate the program. When you run it outside the IDE, it runs the program natively, so you have to put in the prompt to terminate it. This behavior is normal.

 

[Tizen]

Puting return 0 at the end is not neccesary, since it is a standart for C++ compilers to do that if you don't. If its not there, it will be "there" in the exe ;p

The 2x cin.get() is because, when you press enter (if you are entering something with cin) is stays in the input buffer and the first get() swallows it like a sucker ;p Thats why you need the second one.

An alternative is to use cin.sync of fflush, to clear the input buffer

 

[seeker010]

Puting return 0 at the end is not neccesary, since it is a standart for C++ compilers to do that if you don't. If its not there, it will be "there" in the exe ;p

depends on the age of the compiler I guess, so it must be a feature of the 03 standard, not the 98 one.

The 2x cin.get() is because, when you press enter (if you are entering something with cin) is stays in the input buffer and the first get() swallows it like a sucker ;p Thats why you need the second one.

An alternative is to use cin.sync of fflush, to clear the input buffer

never needed two cin.get() with any compiler before; the first cin.get() holds the console app open for input, but once a lr/cr is entered, it should cede the input buffer. Maybe I'll try with VS2k8 later.

 

[gilly_54]

Oh well, no big deal anyways...but if you find something let me know...

 

[Tizen]

depends on the age of the compiler I guess, so it must be a feature of the 03 standard, not the 98 one.

Hm, I think it's in the 98 one... Not to sure though

never needed two cin.get() with any compiler before; the first cin.get() holds the console app open for input, but once a lr/cr is entered, it should cede the input buffer. Maybe I'll try with VS2k8 later.

Hm... I need two cin.get() when I worked with DevCPP...
And I just tried it with Vs2008. No go.

int _tmain(int argc, _TCHAR* argv[])
{
	int a;

	cin>>a;

	cin.get();

	return 0;
}

Building this, enter a number, press enter and it will exit the application

 

[seeker010]

Hm, I think it's in the 98 one... Not to sure though

Codewarrior v5 would always warn me that main needs to return a value if I don't explicitly state a return of 0. I'm pretty sure CWv5 had pretty good C++98 compliance.

Hm... I need two cin.get() when I worked with DevCPP...
And I just tried it with Vs2008. No go.

int _tmain(int argc, _TCHAR* argv[])
{
	int a;

	cin>>a;

	cin.get();

	return 0;
}

Building this, enter a number, press enter and it will exit the application

yes you are right; I didn't realize OP's code had used cin for input. So yeah, you do need to flush the input buffer in that case.

as an alternative, you can do this (which was recommended since Borland 5.02)

#include <iostream>
#include <conio.h>

using namespace std;

int main(int argc, char* argv[])
{
	int a;
	cout << "Hello world!" << endl;
	cin >> a;
	_getch(); //getch() is deprecated
	//return 0;
}

 

[gilly_54]

Ah _getch() does the trick...but the deprecation is discouraging...

 

[Tizen]

The use cin.sync() before cin.get()

 

[seeker010]

Ah _getch() does the trick...but the deprecation is discouraging...

it's not. getch() is deprecated. _getch() is the replacement.

 

[Maz_]

And _getch() is non standard function, I bet it will make your application nonportable.

Also fflush should never be used for stdin, as far as I remember, flushing input buffer results undefined behaviour. fflush should ONLY be used to flush output like contents of some buffer to socket, or contents of some buffer to file.

 

[seeker010]

And _getch() is non standard function, I bet it will make your application nonportable.

Also fflush should never be used for stdin, as far as I remember, flushing input buffer results undefined behaviour. fflush should ONLY be used to flush output like contents of some buffer to socket, or contents of some buffer to file.

_getch() is a standard win32 console function that's not part of the ISO C++ standard. So you can't port it to other systems, but it should be supported by all win32 compilers. most cross platform apps use platform specific preprocessor conditionals anyway because of OS specific functions.

 

[Maz_]

standard and win32 in same sentence
Nothing breaks standards as efficiently as M$... (Honestly, what's wrong with snprintf()??)

And it is true that there's plenty of OS specific functions offered, but it is not true that one cannot write portable code. (I work with platform code which operates on 3 different OSes, windows and linux are 2 of those). And actually only area our platform code does not cower is graphics and sounds. And those can be done by using some portable libraries instead of OS specific graphic libs.

It may well be that I make too big of a fuss about portability here, majority of SW is never ported to other platforms. But it is not my task to tell the thread author that whether he should write portable code or not, I can only give an adviece that some thing is not going to work on other platforms.

And what comes to preprocessor conditionals, it is true that those are used to separate platform specific codes. However in order to use those one must know what works on which platform. Besides in my experience those should be avoided as much as possibly, and when it is necessary to use OS specific code, one should plan carefully how to do it. Badly used preprocessor directives make code difficult to understand and look horrendous. Also larger differences we have in code for each OS, more difficult it becomes to hunt down bugs later. (extensive testing needs to be done on each target platform, if there's plenty of platform specific code. Also variations in operations between platforms are more likely to occurr).

Finally, I would not call WIN API a standard. There's only one C (or C++) language standard (the ISO standard). Rest of the standards do describe something, but no C language.

 

[seeker010]

from what you're describing, you're not using strict ISO C++ standards either, because portable gui libs (gtk, wxwidgets) are not part of the ISO C++ standard. So in essence, you need to separate your definition of portability and standards adherence.

Preprocessor conditionals are absolutely essential when you want to deal with low level OS functions, especially if you want to handle threads in your program, or custom file handling.

For some types of programs portability is very easy, but for other types of programs you are forced to sacrifice portability, at least with the program front end, for efficiency or even possibility.

And in terms of learning C++, portability is secondary to learning the language correctly.

standard and win32 in same sentence
Nothing breaks standards as efficiently as M$... (Honestly, what's wrong with snprintf()??)

And it is true that there's plenty of OS specific functions offered, but it is not true that one cannot write portable code. (I work with platform code which operates on 3 different OSes, windows and linux are 2 of those). And actually only area our platform code does not cower is graphics and sounds. And those can be done by using some portable libraries instead of OS specific graphic libs.

It may well be that I make too big of a fuss about portability here, majority of SW is never ported to other platforms. But it is not my task to tell the thread author that whether he should write portable code or not, I can only give an adviece that some thing is not going to work on other platforms.

And what comes to preprocessor conditionals, it is true that those are used to separate platform specific codes. However in order to use those one must know what works on which platform. Besides in my experience those should be avoided as much as possibly, and when it is necessary to use OS specific code, one should plan carefully how to do it. Badly used preprocessor directives make code difficult to understand and look horrendous. Also larger differences we have in code for each OS, more difficult it becomes to hunt down bugs later. (extensive testing needs to be done on each target platform, if there's plenty of platform specific code. Also variations in operations between platforms are more likely to occurr).

Finally, I would not call WIN API a standard. There's only one C (or C++) language standard (the ISO standard). Rest of the standards do describe something, but no C language.

 

[Maz_]

from what you're describing, you're not using strict ISO C++ standards either, because portable gui libs (gtk, wxwidgets) are not part of the ISO C++ standard. So in essence, you need to separate your definition of portability and standards adherence.

I never claimed so. My original post:

And _getch() is non standard function, I bet it will make your application nonportable.

Also fflush should never be used for stdin, as far as I remember, flushing input buffer results undefined behaviour. fflush should ONLY be used to flush output like contents of some buffer to socket, or contents of some buffer to file.

Preprocessor conditionals are absolutely essential when you want to deal with low level OS functions, especially if you want to handle threads in your program, or custom file handling.

I never told one MUST NOT use preprocessor conditionals/directives I only said:

nd what comes to preprocessor conditionals, it is true that those are used to separate platform specific codes. However in order to use those one must know what works on which platform. Besides in my experience those should be avoided as much as possibly, and when it is necessary to use OS specific code, one should plan carefully how to do it. Badly used preprocessor directives make code difficult to understand and look horrendous. Also larger differences we have in code for each OS, more difficult it becomes to hunt down bugs later. (extensive testing needs to be done on each target platform, if there's plenty of platform specific code. Also variations in operations between platforms are more likely to occurr).

For some types of programs portability is very easy, but for other types of programs you are forced to sacrifice portability, at least with the program front end, for efficiency or even possibility.

And in terms of learning C++, portability is secondary to learning the language correctly.

and I said:

It may well be that I make too big of a fuss about portability here, majority of SW is never ported to other platforms. But it is not my task to tell the thread author that whether he should write portable code or not, I can only give an adviece that some thing is not going to work on other platforms.

So basically I still feel it was ok to bring out the fact that _getch() is not part of ISO standard, and it will result the code to be non portable. I never told the thread author must write portable code, I just informed him/her that if he/she wishes to do so, then _getch() is not a solution.

 

[gilly_54]

Just want to clear up what I mean want and what I need for portability I compile the program, it runs and I don't need to use two cin.gets, I run the program outside the compiler and it doesn't terminate instantly, I try the program on a friends computer and it runs without errors and termination (this is as far as portability goes for me ).
Keep in mind I'm only going to compile win32 console apps for now, don't think I can jump further than that with self-teaching

P.S. I think my brain exploded reading the last few posts...