Why doesn't this work?

[Oni Kami]

Sorry for the un-detailed title, but I couldn't think of a good way to describe this.

So I'm writing this program, and I have a pre-processor command to define a program end (so I can stop using system("PAUSE");, even though I'm just doing simple homework stuff, I'm trying to get into the habit of not using it for the future):
#define end cout<<"Press any key to continue..."<<endl; cin.ignore(numeric_limits<streamsize>::max(),'\n');

There's probably some reason why that's a bad idea, and if there is, feel free to tell me, I'm trying to learn here. Anyways, onto the point, so far it's worked fine for me, just ending my programs with:

end;
return 0;

However, in this program I'm working on, well, I'll throw some lines out there:

int counter;
cout<<"How many lines of data do you plan to input?"<<endl;
cin>>counter;

From there, the program just ends there, it doesn't run "end;", but if I put, "system("PAUSE");" it will run that. To further experiment, I tried this:

string counterStr;
int counter;
cout<<"How many lines of data do you plan to input?"<<endl;
getline(cin,counterStr);
streamline(counterStr)>>counter;

And when I did that, it would run the "end;" just fine.

To further test it, I tried it with cin instead of getline, and instead of "end;" I put:
cin.ignore(numeric_limits<streamsize>::max(),'\n')

At the end of my code, but it would skip that too.

So basically, why can't I get my program to pause properly at the end with cin?

[firedraco]

#defines are evil. Use an inline function instead:

inline void end() {
    std::cin.ignore(std::numeric_limits<streamsize>::max(),'\n');
}

Using cin>>stuff will leave an extra '\n' in the buffer, which "end" will see and remove.

For example, if you type in "32\n" then the buffer will have '3' '2' '\n' and your cin>>count will get '3' and '2' and leave the '\n' in there. Then "end" will see the '\n' and take that, then your program will be done.

Bottom line: Use getline(), it will remove the \n for you.

[jsmith]

And a macro named end is doubly bad since you could now no longer use iterators, since
container.end() would end up a syntax error (ok, pun wasn't really intended, but I
like it so much I had to emphasize it).

Also, that macro definition above, if defined on two lines, is missing a line break (\) after
the first line.

[Oni Kami]

firedraco: Thank you very much.

jsmith: Thank you too, I had a feeling there was some reason it was a bad idea to name it end, and I had no idea there were "end" iterators. I'll give it a better name. And it's defined on one line, it just looks like two lines because of the text wrap in the code box, but thanks for the line break tip.

So is there any simple way to use getline with an integer? I don't like the bulk created from

int x;
string xStr;
getline(cin, xStr);
stringstream(xStr)>>x;

[Oni Kami]

I don't know if we're allowed to bump here, but I'd really like to know if there's an easier way to getline to an int.

[Zhuge]

I don't really think there is any other way beyond using cin>>int, but that leaves that troublesome newline in the buffer.

[Blitz Coder]

trying using

getchar();

or

cin.get();

System ("PAUSE") is very bad. see http://www.gidnetwork.com/b-61.html for why.

[Oni Kami]

Zhuge: Thanks, I was afraid that was the case.

BlitzCoder: I'll try those, but I know System("PAUSE") is bad, that's what this whole post is about, defining a function for the alternative so I can get into the practice of not using it.

[Blitz Coder]

using getchar(); or cin.get(); should solve the need for making your own function.

[Oni Kami]

cin.get(); doesn't work with ints and still puts that newline in the buffer.

getchar(); doesn't work with ints, and after finding that out I didn't test far enough to see if it puts newline into the buffer.

So no-go there Blitz.

So I'm at a loss, there must be something that professional coders do that I'm not getting here. Is there a different way for me to end my program (without system pause) so that I can have newlines in the buffer? Will I always have to convert from strings? What am I not getting here? I doubt all the games I play and programs I use (assuming that even HALF of them are in C++) have all inputted ints as strings and then convert them, there must be something I don't get here.

[Disch]

pretty much the bottom line is that I/O through the console sucks because it's not designed to do the kinds of things homework assignments commonly use it for.

Many console programs don't accept user input at all (nor do they pause) because it kind of defeats the point of having a console program. They're meant to be strung together with other console programs to do a more complex task.

But still... console I/O is taught in school as the introduction to C++ because it doesn't take any work to set up and is pretty basic. But being basic means just that: it's basic.

So don't be surprised if there's not a better way to do something that seems like it should be simple (like getting an integer). I agree, there should be a simpler way, but if one exists I sure don't know what it is (nor do I really care... since I like never use the console).

</unhelpful ramblings>

[Oni Kami]

Don't sell yourself so short Disch, that was much more helpful than you think. I don't know why, but I just didn't think of the fact that I'm just working in the cmd where as all that advanced stuff isn't. Granted, I am still on my first year (first semester even) of C++, that's why all my work is in the command prompt, but anyways, what you said really put it into perspective for me, so thank you.

[jwC5fSEw]

@Disch:

I understand what you said, but what about console games? Obviously today they're not too important, but they are still played in a fairly large niche.

Also, don't get the impression that I'm trying to be a know-it-all; you always seem to have insight about this sort of thing, and I'm curious.

[Disch]

I understand what you said, but what about console games?

I'm not a fan. The console is a terrible medium for games.

There's nothing that can be done in a console game that can't be done 1000x better with an actual window display.

The only plus is that printing text is easier through the console than with most graphic libs.

[Oni Kami]

I completely agree really. I'm only using it because I'm a complete newbie and still learning. I've only been learning C++ since late January.