«

Kevin McCarty <> wrote:
> On Sep 27, 9:05 pm, Brian <bcl...@es.co.nz> wrote:
>
>> Thanks Kevin for taking the time to look more closely at the problem.
>> Originally I typed in all the code including the using namespace std;
>> but Visual Studio C++ did not like the line 'using namespace std;' I will
>> in future write down the error message when something goes wrong.
>>
>> --
>> Regards 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.

--
Regards Brians

[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.

On Wed, 26 Sep 2012 07:54:22 +0000 (UTC), Juha Nieminen
<> wrote:

>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.

Geoff <> wrote:
> On Wed, 26 Sep 2012 07:54:22 +0000 (UTC), Juha Nieminen
> <> wrote:
>
>>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".

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...

Robert Wessel <> wrote:
> 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