I am just curious, I am learning C++ right now from a book called "C++ How to program 2005", But when I type in the code for hello world, I have to make a blank console project because the WIN32 console preset is way different then whats in the book. Plus when I do make a blank project it says the program is outdated. Here is the code they give for it. 1 // Fig. 2.1: fig02_01.cpp 2 // Text-printing program. 3 #include <iostream> 4 5 // 6 int main() 7 { 8 std::cout << "Welcome to C++!\n"; 9 10 return 0; 11 12 } --------------------------------------------- The code of the preset WIN32 console application starts out like this... // HW.cpp : Defines the entry point for the console application. // #include "stdafx.h" int _tmain(int argc, _TCHAR* argv[]) { return 0; } ---------------------------------------------- So, basically, what I am trying to ask is, How would make the screen say "Hello World!", in this second code here, the most up-to-date WIN32 Console way, I guess...

The most basic "hello world" program in C++ is a program that outputs "Hello World" to the standard output, and then exits without error. This is accomplished with:



Note the absence of a return statement in the main function, since it's implicitly added by the compiler (although I suspect the book kept it there to keep you from being confused).

By compiling a file containing this code, you should get a working program with no errors. If you get any errors, you might have a problem with your compiler configuration, so post the exact error here. In practice, the default code in most IDEs is useless (especially to a beginner) so use empty projects as often as you can.

Quote:Original post by Kaycon11
Here is the code they give for it.

1 // Fig. 2.1: fig02_01.cpp
2 // Text-printing program.
3 #include <iostream>
4
5 //
6 int main()
7 {
8 std::cout << "Welcome to C++!\n";
9
10 return 0;
11
12 }
---------------------------------------------

I'm surprised that a recent C++ book didn't use..
std::cout << "Welcome to C++!" << std::endl;

your first method is in c++, the second method is in visual c++ - to an extent the same language but also not.

i'm not sure why it says your project is outdated unless you're making changes then hitting the big green play button, then you'll get a message about your project being outdated and whether it should rebuild. (I'm kinda speaking off of the top of my head cause i just click the don't notify me again checkbox the first time it appears)

for c++ in visual studio:

file -> new -> project -> empty project

if you want a really excellent c++ book get jesse liberty's learn to program c++ in 21 days! Out of all the beginner c++ books I've seen its by far the best!

Quote:Original post by Degra
I'm surprised that a recent C++ book didn't use..
std::cout << "Welcome to C++!" << std::endl;

Because it would be pointless: adding the newline to the string is shorter, and the implicit stream flush caused by std::endl would happen anyway as the program ends and sends an end-of-stream to the standard output.

It's still better practice to use endl. The only time it's ever helped me is when my program crashed before the stream flushed, but it's good practice so you don't EVER run into that problem. Especially since using cout to test for errors, then not having the stream flush defeats the whole purpose of using cout to test for errors!

The escape sequence is good for safe, non-crashable code, but since we'd like to think of all code as non-crashable, it's always better to use endl.

Quote:Original post by Splinter of Chaos
It's still better practice to use endl. The only time it's ever helped me is when my program crashed before the stream flushed, but it's good practice so you don't EVER run into that problem. Especially since using cout to test for errors, then not having the stream flush defeats the whole purpose of using cout to test for errors!

The escape sequence is good for safe, non-crashable code, but since we'd like to think of all code as non-crashable, it's always better to use endl.

Then super-strictly speaking, you also need to #include <ostream> for std::endl, because it doesn't have to be declared by <iostream>.

Quote:Original post by Splinter of Chaos
It's still better practice to use endl. The only time it's ever helped me is when my program crashed before the stream flushed, but it's good practice so you don't EVER run into that problem. Especially since using cout to test for errors, then not having the stream flush defeats the whole purpose of using cout to test for errors!

The screwdriver not being heavy enough defeats the whole purpose of using a screwdriver to hit nails!

So, you're using std::cout to test for errors, find it inadequate because it buffers output, and thus apply the std::endl band-aid to make it fit, and then you advertise the resulting brittle contraption as best practice? Sorry, but no thanks.

The first issue with this is that you're using bad language-level tools. Given that std::cout was not designed for testing errors, and std::cerr was, using the former instead of the latter strikes me as a poor choice. Especially given that, since std::cerr is unbuffered, you don't have any stream-not-flushed issues! But even if we assume for a moment that you like std::cout more (why anyone would write error-testing text to the standard output stream instead of the standard error stream is beyond me), you can remove the buffering on std::cout using std::cout.rdbuf()->pubsetbuf(0,0); and this avoid to write all these annoying std::endl everywhere!

The second issue is that you're using bad development tools. For all intents and purposes, any situation in which you can afford write error-testing junk to the standard output is a situation where you have your compiler available. And, by extent, you can instead use the debugger available on your development computer to determine the exact position of the error, because this is precisely what it was designed for and is an order of magnitude more efficient that looking for the error by hand using logging code. The only situation where I would see debug-by-logging-strings as a good practice would be developing for an embedded device where no remote debugging is available, and that situation is so rare that it's hardly relevant when deciding what a best practice is (and even then, you should be using an unbuffered stream anyway).

The third issue is that the scope of this "best practice" is way too limited. The vast majority of text being output in a non-trivial professional program is output to an unspecified stream (because this allows outputting that text to a file, to a stringstream, or to any of the standard streams) usually by implementing operator<< for a custom object. And, trust me, you don't want to flush every line when you're writing a 100-megabyte file to disk, thus flushing should not be used in the vast majority of cases, let alone std::endl.

Quote:The escape sequence is good for safe, non-crashable code, but since we'd like to think of all code as non-crashable, it's always better to use endl.

Even if I had agreed with the previous discussion, I have a real hard time picturing a Hello World application as code that could crash in-between two string outputs. Good practices should be applied thoughtfully, not automatically, lest they become applied to situations where they do not fit. Namely, in a Hello World situation, std::endl provides no benefit, but makes the code longer and slightly more complex.