Jump to content
  • Advertisement
Sign in to follow this  
Kaycon11

C++ - Whats the most up-to-date form of "Hello World"?

This topic is 3742 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
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:

#include <iostream>
int main()
{
std::cout << "Hello, World!\n";
}


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.

Share this post


Link to post
Share on other sites
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;

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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>.

Share this post


Link to post
Share on other sites
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.


Except for two things.

First, this was supposed to be a minimal Hello World program. And the code shown above doesn't need std::endl to correctly print Hello World.

And second, flushing your stream all the time carries a performance cost. Usually, not a problem (and as you say, in cases where you use it for debug output, you *want* to flush after every statement), but if you're printing out a lot of text, and it's not just for debugging purposes, it's a lot better to just flush once, at the end, and not at every line break.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Coldon
your first method is in c++, the second method is in visual c++ - to an extent the same language but also not.


I'm no expert, but this doesn't sound right to me. Can someone confirm? Isn't the OP just using the Win32 library, not some "C++-variant", and that this code could work on any compiler that Win32 supported.

@ToohrVyk: printf-ing/cerr-ing are sometimes necessary for debugging. For example, my robotics team must use them, since we have no debugger available for the compiler that we're using. And even if we could, we can't exactly use a breakpoint in the middle of the robot crashing into the wall - what would you expect the motors to do?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!