Friday, March 30, 2012

The Basic Commands

Here's more of what I've learned so far. The basic stuff cont (not basic as in BASIC :))

Whitespace - The compiler mostly ignores blank spaces aka whitespace. Whitespace is used mostly for us humans so we can read the code easier.

#include - This is a preprocessor directive. It tells the program what to include in your program. A file that you include in the program is called a header file. Examples of some header files and how to write them:

#include <iostream>
#include <string>
#include <vector>

// commenting - If you want to comment on some piece of code to make it easier for you or others to understand what it does then type // for a comment that is only one line or /* */ for multiple lined comments. Example:

// This is my comment
#include <iostream>

/* This is
my multiple
lined comment.*/

#include <iostream>

Functions - A function is a group of programming code that does some work and can return a value. More on functions later, but for now all you need to know is that you need to have a main() function in every program. Example:

#include <iostream>

using namespace std; 


I'm probably repeating myself but get used to that. You'll be repeating yourself in the code many many many times or at least I am. To really understand anything I have to play around with it. Trying different things and seeing if it works. Now onto more basic things.

cout - I didn't mention before that cout is a string literal which means it's literally the characters between the quotes.

cout is an object from the iostream (header file we included in the first program).

<<  - The name for this is output operator. Like I said before, it takes whatever is on the open ended side and puts it in the closed end side.

If I wasn't using "using namespace std;" then I would have to attach a prefix to the cout string literal. For example without using namespace std;

#include <iostream>

       std::cout << "Prefix example.";
       return 0;

That std is a namespace which tells the compiler where to look for "cout". In this case the compiler looks for "cout" in the standard library. It's like an area code. Without that area code the compiler wouldn't know where to look for cout.

That is where "using namespace std;" comes into play. This little line of code loads the standard library into the program so you don't have to type an area code every time you want to use cout or anything else from the standard library. I'm sure there are reasons to use a prefix with every line of code, but for what I want to accomplish I think for now it would be much easier if I don't have to type that in every time I want to write an object from one of the libraries. I would have to do that with every single object I used. Example:

#include <iostream>

      std::cout << "Another example." << std::endl;
     return 0;

Since both cout and endl are in the standard library I would have to tell the compiler where both of them were.

This of libraries like this:

There's the standard library. Within that is iostream. Within that is cout.

 ; - I mentioned this before, but I'll get more techincal this time around.

All statements must end in a semicolon. cout << "blah blah blah" << endl; is  a statement so it needs a semicolon. Simple as that. Just like most sentences need a period or some other form of closing punctuation.

return 0;

This will be explained more when dealing with functions, but for now just think of this as the off button.

So let's wrap up so I don't keep repeating myself next blog entry.

We've learned about:

functions (tiny bit)
cout (a string literal)
return 0

I apologize in advance if you really are trying to learn something about C++ by reading this. I'm still learning myself and my thought process is all over the place. I'll try to keep things more organized from now on.

Well to all the little bots that live in the void that is my blog, see you next time.
Same rat channel.
Same rat time.....maybe :D


  1. If you're new to programming, here are a few things I wish someone had told me when I was just starting, because it took me years to unlearn bad habits. If you're not, please ignore them.

    (1) Decide on a coding standard and stick to it.

    That means where to put the whitespace, where to put the comments and how to format them, what system you use to name variables, constants, members, globals, and other things that need naming. It makes the code way more readable, which means way easier to manage, which eventually means way fewer mistakes. If you'll eventually work in this field, you'll probably have to learn a different coding standard, but that's OK, it's easier to switch between them than to learn to use one in the first place.

    (2) If you find yourself not using a chunk of code, delete it immediately.

    Don't just comment it out, delete it. Or, OK, you can comment it out, but then keep a rule that if you happen upon a block of commented-out code, *then* delete it. Otherwise your code will end up an unreadable mess of commented-out blocks with actual running code in little islands here and there.

    (3) Use a source control system.

    Like, NOW. Even for your little personal practice projects. It'll give you the courage to do (2) because code you delete won't really be gone; you can always bring it back with a rollback. If I was starting now, I'd pick GIT although Subversion gets the job done too. You can't learn good programming techniques without a source control system to lean on.

    (4) Comment all—and I mean *all*—of your methods/functions/subroutines/modules. A line or two will usually do it. It's most important to write down what the thing is for, and what or who uses it. If it's complicated, you might also note what it does and what happens next. Along the lines of:

    * Initializes the user interface. Triggered on startup.
    * Continues with _readConfiguration.

    And good luck.

  2. I'm definitely new to programming and welcome any and all helpful tips. That's part of the reason I'm posting this on a blog. It's my hope that friendly netizens will stop by from time to time to offer some advice.

    I don't think I'll ever work in this field because I'm not going to have any "formal" training. I'm doing this all through books, videos, forums and any/all online resources I can get my grubby mits on.

    My hope is that in ten years time I'll be able to make a game or two or just the simple fact of being able to understand what people are talking about when they talk about source code. Coding is like a whole other world that I've been connected to my whole life, but never understood.

    Anyway, I want to thank you for those tips. I've read some horror stories from Jay Barnson's blog on source control systems, but I didn't think since I'm just a one man operation that I would need that. Definitely rethinking my position on that now.

    Anyway, if you want some great stories about game development Jay's got a ton of them and is partly the reason I've decided to try my hand at this. This post in particular: piqued my interest.

    Thanks again for the tips.

  3. I don't have any formal training either, and I've worked full-time in the field for eleven years this year, part-time for longer than that. Once nice thing about the software development world is that credentials matter much less than in most other fields; what matters is what you're able to do.

    C/C++ is very useful to teach you how a computer works; it's quite close to the way a microprocessor "thinks" in a way. The connection between the code you write and the code the computer runs. On the other hand there's a lot of micromanagement; if you want to actually get something done, you'll end up using libraries that can be used in any language, and languages specifically created to be written that way are usually better at it.

    But if you want to learn good, solid, practically useful programming skills—for game development or many other purposes—C/C++ is a really good basis, which you can then complement with something like Python, for example. A lot of apps these days are developed in Python and then coding the bits that need heavy optimization in C or C++.

    You might also want to try your hand at some of those environments sooner or later. You can actually make perfectly reasonable little games in weeks rather than years in them, even if you start from zero. For that, I'd suggest Android or iOS, or, especially if you have some background with web page design, the browser—they're dead easy and very rewarding environments to work in.

  4. I read a lot of different forums before choosing C++ and they all pretty much said what you said, "C++ is the best place to start." In a year or so I'm hoping to be able to try out python, but for now I'm keeping my expectations very very small.

    I go to some of these coding sites and am just overwhelmed with what they're talking about and the code that's written, but then I remember to take bite size chunks, don't try to eat a whole cow in one go. :D (Corny saying, but my grandfather was fond of farm metaphors and it applies so well to C++.

    In any case, thanks again for the encouragement.

    One question, my organizational skills are......lacking. Do you have a suggestion on coding standards or a website that teaches about good practices, (naming conventions, use of whitespace, etc).