cout does not work

[Brian]

All I can say is that it works for me with VC++ 10 (Visual Studio
2010), see my copy-and-paste from a terminal window below.

I still believe there was a typo on your first try... but it's hard to
say for certain, as I don't think you ever provided your entire piece
of failing code. Only hand-copied excerpts which had their own
additional typos

One more time, when asking on Usenet (or anywhere else) about compiler
error messages, do NOT just hand-copy them down; you need to COPY-AND-
PASTE the error messages and also your entire piece of code into your
post, or it is almost certain that there will be typos that prevent
others from diagnosing the actual problem.

Good luck, and sorry I couldn't help any further,
- Kevin B. McCarty


D:\users\kevin> type hw.cpp
#include <iostream>
using namespace std;

int main()
{
cout << "Hello world!" << endl;
return 0;
}

D:\users\kevin> cl /EHsc hw.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64
Copyright (C) Microsoft Corporation. All rights reserved.

hw.cpp
Microsoft (R) Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.

/out:hw.exe
hw.obj

D:\users\kevin> hw.exe
Hello world!

When I get a spare moment I hope to try entering the code again but this
time I will write down any error messages.
I tend to send e-mail on my iPad so its not possible to cut and paste
between two computer and I have the newsgroups setup on my iPad. But I
could e-mail it to myself and receive the e-mail on my iPad then cut and
copy it to this newsgroup.
The reason I use a iPad is that its ready to use as soon as you switch it
on and its very portable, light in weight.and not too big.

 

[Gasconheart]

I'm having exactly the same problem than Brian.
Book: Mike McGrath, C++ Programming in easy steps
Page 12, code:

#include <iostream>
using namespace std;
int main()
{
cout << "Hello World\n";
return 0;
}

and I swear to God, no typing error whatsoever there.
When using Bill Gates' Visual C++, it gives this error message:


--------------------Configuration: p12 - Win32 Debug--------------------
Compiling...
p12.cpp
c:\archivos de programa\microsoft visual studio\myprojects\p12\p12.cpp(10) : fatal error C1010: unexpected end of file while looking for precompiled header directive


When using Code::Blocks it works flawlessly, both in Windows and Linux.
Which is flabbergasting.
I also would like to begin to understand what the heck plus plus is going on here.
I've come back to programming after a long twenty-five-years-old nap. My only prior experience was the BASIC of my domestic Sinclair Spectrum.
How things have changed. I was one of those who couldn't live without the goto.

It sounds weird to me that only this Brian fellow and I have had this particular problem.

I can use Code::Blocks, but I'd like to focus on Visual C++, as I bought some books on this. Please, mighty fellows, help me begin to understand.

Regards

Gasconheart.

 

[Geoff]

Start your program from Visual Studio by pressing ctrl-F5, and the window
will stay open until you press a key.

That's a nice feature but ctrl-F5 is "start without debugging" while
F5 is "start debugging".

The preferred method for most uses of the debugger is to set a
breakpoint at the expected program termination point. This will keep
the debuggee window open until the process is terminated by the
debugger or you execute past the breakpoint. The obvious disadvantage
of breakpoints is that you have to place them at all the exits if your
program has more than one.

 

[Juha Nieminen]

That's a nice feature but ctrl-F5 is "start without debugging" while
F5 is "start debugging".

I really can't understand what's Microsoft's rationale behind having
the pause only when you start in non-debug mode, but you should be
complaining to them...

 

[Tobias Müller]

If you set a breakpoint at the beginning of the program*, and then use
ctrl-F5, you'll be able to debug from that point on, and the console
window will stay open at the end.

If you start with ctrl-F5, no debugger will be attached and all breakpoints
are simply ignored.
The only way to debug is in that case to manually attach the debugger to
the process.

The one downside is that it's tough
to debug things that happen before the first line of main() (such as
the execution of constructors for global objects).

The application does needed to be linked with /SUBSYSTEM:CONSOLE
(which should be there if you started the project as a console
application, but IIRC, the default has changed if you start with an
*empty* project).

If you compile/link without /SUBSYSTEM:CONSOLE, you don't even have a
console. If you don't have one, you shouldn't care much whether it will be
closed or not.

This is an annoying property of VS, and has been for many years. The
reason for the difference is that VS runs a "without debugging"
application differently - it actually creates a batch file to run the
program, and puts a "pause" at the end of that, and then runs the
batch file - "with debugging" starts the program directly under the
control of the debugger. Still this is annoying enough that MS should
have found a way to fix it, even though it might require as OS change.

Put a breakpoint on the closing brace of main(), and the console will stay
open. Where's the problem?

*Alternatively put a DebugBreak() call at the beginning of main(), and
you don't have to remember to manually set the breakpoint there.

Which I'd consider even worse than putting getc() at the end of main().

Tobi