0

Shouldn't this work? I mean, the code is merely a test and is meant so that the dialogue goes this way : What is your name? name here, Hello name here, and yet it does not show the last line of Hello after I type in my name and click enter it just dissapears. Here is the code. 

#include <iostream>
#include <string>

int main (void)
{ 
    using std::cin;
    using std::cout;
    using std::string;
    string name = "";
    cout << "What is your name, pls?\n";
    cin >> name;
    cout << "\nHello " << name.c_str() << "\n";
    return 0;
}
Jason Licker
  • 3
  • 3
  • 4
    Use `cout << std::endl` – Basile Starynkevitch Aug 13 '13 at 19:59
  • 2
    Disappears? Make sure that the console stays open after the program has finished if you use VS or other similar IDEs. – Zeta Aug 13 '13 at 20:00
  • How are you running your program? – David Heffernan Aug 13 '13 at 20:00
  • 1
    Or, you can just run the program from the console/command line. –  Aug 13 '13 at 20:00
  • possible duplicate of [How do I keep open the console?](http://stackoverflow.com/questions/14349036/how-do-i-keep-open-the-console) – Josh Lee Aug 13 '13 at 20:03
  • http://stackoverflow.com/questions/1775865/preventing-console-window-from-closing-on-visual-studio-c-c-console-applicatio – Josh Lee Aug 13 '13 at 20:04
  • 4
    Although C++ has the `endl` manipulator, `\n` is fine in this situation; that is not the answer. – Kaz Aug 13 '13 at 20:07
  • 1
    `endl` will work but the underlaying problem is your not flushing the stream before you close it. try `std::flush` or `std::endl` – andre Aug 13 '13 at 20:30
  • 2
    @andre Since when do streams need to be explicitly flushed before closing? – Kaz Aug 13 '13 at 20:38
  • @Kaz The draft std from 2011 says something about cout controlling output to the C output stream for stdout, but I'm not seeing anything about *that* output not being buffered, and the destructor for `basic_ostream` simply says that it doesn't perform any operations on `rdbuf` (27.7.3.2). I'm no expert, but in any case (whether I'm right in my interpretation or not), it's still good practice to flush streams to have a well-behaved prog, and thus worth spreading around as positive advice rather than debasing it. – user Aug 13 '13 at 21:23
  • 1
    @andre and @Atash: Explicitly flushing the stream is not needed. When the underlying `std::basic_filebuf` is destroyed it calls `close()` which flushes any pending output. – Blastfurnace Aug 13 '13 at 21:50
  • @Atash Even without looking at the document, I would hardly expect something called `rdbuf` to be related to output. `cout` is almost certainly buffered: line buffered if connected to an interactive display, otherwise fully buffered. You generally have to do something explicit in the program to get an unbuffered stream (in C stdio or C++ streams). Closing streams explicitly or at least flushing explicitly is a good idea when you have some kind of garbage collection scheme: otherwise the flushing of the data is deferred to some unknown point in time (finalization). In this case, no. – Kaz Aug 13 '13 at 22:59
  • @Kaz `rdbuf` Is associated with the basic I/O classes (see http://www.cplusplus.com/reference/ostream/ostream/ for a quickie) and is stated to be associated with all input/output operations (and this is present in the doc, too). That said, do you actually promote implicit behavior in this case, where such confusion amongst programmers (see the sheer number of 'answers' to this question for case in point) runs rampant? – user Aug 13 '13 at 23:12
  • @Atash Anyone who thinks that output is not flushed when you destroy the object or exit the program (non-abruptly!) is severely confused. – Kaz Aug 14 '13 at 00:39
  • @Kaz [citation needed] – user Aug 14 '13 at 00:52
  • @Atash: The documented behavior is to flush any pending output when the stream object is destroyed. Telling someone to manually flush the stream, just in case, is cargo-cult programming. – Blastfurnace Aug 14 '13 at 00:54
  • @Blastfurnace Could I please get a section number? A quotation? Something supporting this claim instead of the incessant in-your-face-this-is-obvious-nonsense? I'm willing to change my position, but I need *evidence*. – user Aug 14 '13 at 01:01
  • @Atash: `[filebuf.cons] 27.9.1.2 paragraph 5` and `[filebuf.members] 27.9.1.4 paragraph 6` – Blastfurnace Aug 14 '13 at 01:04
  • @Blastfurnace Last I checked `cout` was an `ostream`, not an `ofstream`. Where does it state that `cout` uses file buffers? – user Aug 14 '13 at 01:08
  • 1
    @Atash: It took some digging but I found `27.5.3.1.6 Class ios_base::Init [ios::Init]`. The class that constructs the standard streams (cin, cout, etc) calls `flush()` on each when it is destroyed. – Blastfurnace Aug 14 '13 at 01:41
  • @Blastfurnace A'ight. I've been converted. Thanks for the info! – user Aug 14 '13 at 01:44
  • @Atash: Sorry my first reference was wrong but I knew the C++ committee wasn't completely insane. – Blastfurnace Aug 14 '13 at 01:46
  • @Blastfurnace They named the buffer `rdbuf`, gave us destructors that could wreck the program by throwing on stack unwind, several really strange template constructs involving extern, and the totally unimplementable `export` keyword. I didn't have that faith. >_< EDIT: correction: *almost* totally unimplementable. But seriously, thanks! – user Aug 14 '13 at 01:48

7 Answers7

3

My guess is that you are running from the debugger, or double clicking the executable. In either of those cases, when the program ends, the console will close. So, the program produced output, but you just could not see it before the console closed.

Run the program from a pre-existing console so that the console remains after your program ends. Or, just whilst debugging, arrange that your program does not terminate immediately after emitting its final output. A simple way to do that is to place a break point at the end of the program.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • 3
    Whatever you do, don't arrange so that your program doesn't terminate. That's a terrible habit to get into. Launch your program properly rather than breaking the program so that it can be launched improperly. – David Schwartz Aug 13 '13 at 20:03
  • @David For hacky debugging purposes it's OK no? – David Heffernan Aug 13 '13 at 20:05
  • @DavidHeffernan Is there a particular use case where you can debug a program that purposely doesn't terminate, but not a program that does? – Dennis Meng Aug 13 '13 at 20:55
  • @DavidSchwartz It was my point. What you say is very true. But nothing I have said contradicts you. – David Heffernan Aug 14 '13 at 06:12
  • Thank you so much for making me realize that my IDE does not have "Run without debugging" and making me realize that I should start using VS, yet I hopped upon another problem when running this exact same code in VS with the option of "Run without debugging", here is the problem >> 1>LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt, that is the problem it gives me when I run the code without debugging. – Jason Licker Aug 15 '13 at 19:41
  • I cannot explain that. That would be a new question. If you do ask a new question try to give as much detail as possible. – David Heffernan Aug 15 '13 at 19:44
1

It probably showed it right before it disappeared. If you're going to write console programs, and if you're going to send output to a console, you should run them from a console so the output has some place to go.

David Schwartz
  • 179,497
  • 17
  • 214
  • 278
1

After you are done with your program, press Ctrl + F5 ( Run without debugging). This will prompt before closing the window and this is what you want.

JNL
  • 4,683
  • 18
  • 29
1

Make sure you put a breakpoint before main goes out of scope. I guess your console disappears under VS?

Also, you don't need to extract the char* in the last cout statement:

cout << "\nHello " << name << endl;

Jason
  • 409
  • 2
  • 7
0
  1. Open a terminal (or a command prompt window).
  2. Navigate to the folder that contains the executable.
  3. Run it.

It's not disappearing. It is just running really fast.

Every IDE has a keyboard shortcut that allows you to run code and pause after the execution has finished.

This keyboard shortcut is Ctrl-F5 in Visual Studio.

I have no idea what IDE you're running, but that is your basic problem.

The other thing you can do is to test your code in ideone : ideone.com/hb4Cel (it's the same code. There is no point pasting it here)

Carl
  • 43,122
  • 10
  • 80
  • 104
-1

A dirty workaround is to add something like this

cin >> name;

at the end, just before return 0;. It forces the window to wait for input (i.e. hitting return) before returning (which closes the program).

This isn't necessarily good design, but if all you want to do is run some tests then it'll do the trick.

Kyle G.
  • 870
  • 2
  • 10
  • 22
  • There's no reason to suspect the OP is looking for a dirty workaround or bad design. It seems much more likely he's trying to learn how to do things properly. – David Schwartz Aug 13 '13 at 20:27
-2

Basically when you enter your name it displays your last line and exits after return 0. Here are the following things to avoid that
1- use command line to run the application
Start->accessories->command prompt Go to folder in which your application is using cd command

 c:>cd c:\path\foldername


Now run the application by typing the program name e.g 

 c:\path\foldername>my_application.exe


It will display your last line.

2- Now if your are using microsoft visual c++ press ctrl+F5 to run your program

3- This is not recommended but you an use it as long as your are debugging then remove it from the code afterwards. Include conio.h header file and add getch(); line before return statement. It would hold the screen for you till you press a key.

Himanshu Pandey
  • 726
  • 5
  • 13