# [C++] Tutorial in progress

## Recommended Posts

I am currently writing a (free, online) C++ tutorial. The first three chapters are here. More will follow shortly. EDIT (08/07/07) The bulk of chapter 3 is online.
Message to advanced C++ users of the forums: The philosophy that I ascribe to is explaining not how the language tools (functions, objects) can be used to accomplish things, but rather how they are used to apply the Once, Twice, Refactor principle. I also choose to introduce SC++L and boost concepts by example, before mentioning their C-legacy counterparts. I intentionally restrict the scope of my statements (for instance, saying that a function must be defined before it's used) until I have presented enough concepts to add more nuances (the existence of forward declarations). However, if you notice details that are outright wrong, or confusing wordings, feel free to PM me or reply to this thread. [Edited by - ToohrVyk on July 8, 2007 4:16:09 PM]

##### Share on other sites
An admirable task, and although you certainly go for the throat (bringing up undefined behaviour early etc) and try to teach good practises from the beginning, while I read it I couldn't help feeling that a "non-programmer" would be slightly lost in parts of this tutorial.

There is a very delicate balance between language a non-programmer will and won't understand. I mean when I was starting out I remember finding it hard at times to follow even the simplest tutorials.

That said I wish I could point you at specific pieces of your tutorial which give me this impression, but I can't. I just feels a little "too technical", which IMO is unfortunately due to the nature of the language itself. Any other article which doesn't address this isn't doing the complex nature of the language justice. Another reason why C++ isn't highly recommended as a beginning language I suppose. (no chance you would put a reference to this fact in your tutorial? [grin])

On a slightly different note, I would highly recommend you include a section about dealing with errors at the end of each chapter. Many books assume the reader will not make typing errors trying out the code. How many times have we seen someone who cannot compile their first program because they mistyped std::endl?

Think of common mistakes (missing semicolons, missing parentheses, std:string) and try explain the errors the compiler comes out with. Since you are making a website, you may find it easier to simply include a link to "dealing with common errors" rather than detailing them inline.

When I started out I don't remember ever seeing a book that tried to explain the meaning behind the error messages. Although you have already included one or two compiler errors they aren't the ones a new programmer would typically have to deal with. Even just explaining that the error message includes an error code which can be used to google the error source would be a good idea.

##### Share on other sites
The "frequent errors" section already existed in the french version draft of the tutorial. I'll make sure to include something similar, though possibly (as you suggested) not inline. Chapter 4 sounds like a good place for compiler errors and debugging [smile]

As for mentioning that C++ is not adapted to beginners... no need to scare the readers: if they don't gather that fact from the concepts presented in the tutorial, I would say it's their problem [grin] you're right that the concepts are indeed quite technical, though, but sadly that's what they are—feel free to mention any unnecessary technical, though.

##### Share on other sites
I only looked over the first chapter briefly but It looks like a great start for C++.Also liked how you explained concepts with graphics and such.
I'm sure it will be a great resource for C++ beginners.
Keep it up!

##### Share on other sites
I like it :)

But I found a few issues. I havn't read all of it so I could have missed something :)

Your main function doesn't return anything in every example. Also I would write something about datatypes before you start talking about references.

Some questions a beginner might ask him/her self:

- std::string, what do the colons mean?
- You're using spaces and tabs, when should I use a space and when should I use a tab.

Suggestion: Explain how to deal with errors and warnings. When I just started programming, I never actually "read" the error. It was more like: "oh my god, an error, what now?" That's a common mistake made by beginners. They know they have an error but they just don't know how to fix it because they're not reading it right.

I would also write something about the usage of google. "How does one convert a string to an integer?" Write something about how to use google right.

Good luck :)

##### Share on other sites
Quote:
 Original post by WalterTamboerYour main function doesn't return anything in every example.

This is idiomatic in C++, as an implicit return 0; is added at the end of the function.

Quote:
 Also I would write something about datatypes before you start talking about references.

Well, references are independent of data types, and data types in themselves are an extremely complex subject (basic types, arrays, pointers, classes, class templates, typedefs) ... since I had to explain that auto variable definitions create a value, I felt that it would be correct to introduce references (which don't create a value) there as well.

Quote:
 - std::string, what do the colons mean?- You're using spaces and tabs, when should I use a space and when should I use a tab.

Excellent suggestions, thank you!

Quote:
 I would also write something about the usage of google. "How does one convert a string to an integer?" Write something about how to use google right.

boost::lexical_cast<std::string>(i); will be in the tutorial [smile] I'll make sure to add explanations about how to get help.

##### Share on other sites
Quote:
 Original post by ToohrVykThis is idiomatic in C++, as an implicit return 0; is added at the end of the function.

You don't know that as a beginner :)

Quote:
 Well, references are independent of data types, and data types in themselves are an extremely complex subject (basic types, arrays, pointers, classes, class templates, typedefs) ... since I had to explain that auto variable definitions create a value, I felt that it would be correct to introduce references (which don't create a value) there as well.

Uhm... You're right. I'm with you.

##### Share on other sites
Quote:
Original post by WalterTamboer
Quote:
 Original post by ToohrVykThis is idiomatic in C++, as an implicit return 0; is added at the end of the function.

You don't know that as a beginner :)

Quote:
 Chapter 2, Section 3.3: "Return Values"If a function is defined as returning a value of a certain type, but no return encountered when executing the function, undefined behaviour occurs. Compilers often generate a warning about the absence of a return statement. The only exception is the main function: if the return statement is missing, the function will act as if a return 0; statement was present.

[wink]

##### Share on other sites
Quote:
 Chapter 2, Section 3.3: "Return Values"If a function is defined as returning a value of a certain type, but no return encountered when executing the function, undefined behaviour occurs. Compilers often generate a warning about the absence of a return statement. The only exception is the main function: if the return statement is missing, the function will act as if a return 0; statement was present.

I'll shut up now [wink]

##### Share on other sites
Very detailed tutorials. I wish they had of been around when i first learned C++.

##### Share on other sites
The bulk of chapter three (everything except the summary and exercises) is now online. It deals with control structures.

##### Share on other sites
Victor i've followed your advice for several years now :-) And i'm so happy you are writing tutorials... And yes some parts may show advanced topics but I think it is better to know what can go wrong instead of coding happily until one day DUN DUN DUNN THE FATAL ERROR!
-durfy

##### Share on other sites
IMHO you need to start way further back.

Quote:
 Programming in C++ involves writing code: a document containing text and symbols describing in a predefined way what the program should do. The grey box below contains an example of C++ source code, for a program which displays "Dura lex, sed lex" in a console window:

What is C++? Programming *involves* writing "code", but what *is* it, and why would I want to do it? What are "symbols", and what am I supposed to make of the phrase "describing in a predefined way"? Why are you showing me all this sample code right off the bat (also, most readers aren't going to know Latin; I took four years of it and don't recognize that sentence as anything "special" although I could translate it)? And what's a console window?

The goal of starting where you do is admirable, though - just the presentation is going to need a lot of work. (I'd rather introduce undefined behaviour specifically at the first opportunity in sample code to *create* some, and before that simply allude to the idea that C++ is "evil" in that wrong code can appear right.)

I'd also suggest keeping things compiler/IDE agnostic; you can talk about your favourite IDE in an appendix, but as it stands, you miss an opportunity to get the student familiar with the command line (which will be very useful) - which will later either leverage a profitable discussion of "how/why shouldn't I pause the program at the end", or else let the student sidestep that entirely. :)

When I had the idea of writing a book, I wanted to do two whole chapters before any code - the first on "what is programming" and the second on "what is C++", basically. And then in the chapter after that, I would build up the first "meaningful" program from simpler ones - starting with just 'int main() {}'.

That is, for several iterations, the program wouldn't even appear to do anything, because the student needs to see the principles from the previous chapter in practice before working his/her way up to I/O. The student would instead take it on faith that the calculations are happening - or not, as this gives an opportunity to describe compiler optimization. And of course, this is an opportunity for the student to practice thinking abstractly :)

##### Share on other sites
Quote:
 Original post by ZahlmanWhen I had the idea of writing a book, I wanted to do two whole chapters before any code - the first on "what is programming" and the second on "what is C++", basically. And then in the chapter after that, I would build up the first "meaningful" program from simpler ones - starting with just 'int main() {}'.

So, when's your book coming out [grin]?

##### Share on other sites
Quote:
 Original post by ZahlmanWhat is C++? Programming *involves* writing "code", but what *is* it, and why would I want to do it? What are "symbols", and what am I supposed to make of the phrase "describing in a predefined way"? Why are you showing me all this sample code right off the bat (also, most readers aren't going to know Latin; I took four years of it and don't recognize that sentence as anything "special" although I could translate it)? And what's a console window?

You're right, that would require some clarifications. On the other hand, I don't want to run the risk of boring the reader before he even starts doing things—he might just decide to skip to more interesting things.

Quote:
 I'd also suggest keeping things compiler/IDE agnostic; you can talk about your favourite IDE in an appendix, but as it stands, you miss an opportunity to get the student familiar with the command line (which will be very useful) - which will later either leverage a profitable discussion of "how/why shouldn't I pause the program at the end", or else let the student sidestep that entirely. :)

I would save that for later. Although I guess I should include the fact that "run without debugging" keeps the window around so that readers do not start trying to keep it around themselves.

In the end, setting up VC++ and using it is shorter than setting up a console and compiler on Windows, and it would require IMHO too much work to get running.

Quote:
 That is, for several iterations, the program wouldn't even appear to do anything, because the student needs to see the principles from the previous chapter in practice before working his/her way up to I/O. The student would instead take it on faith that the calculations are happening - or not, as this gives an opportunity to describe compiler optimization. And of course, this is an opportunity for the student to practice thinking abstractly :)

This I completely disagree with—I have always found instant feedback to be immensely useful when teaching Caml programming. Instead of an act of faith about the calculations happening, I would rather have an act of faith about how "throwing things at std::cout" works.

Thank you for the input [smile]

##### Share on other sites
Quote:
Original post by ToohrVyk
Quote:
 That is, for several iterations, the program wouldn't even appear to do anything, because the student needs to see the principles from the previous chapter in practice before working his/her way up to I/O. The student would instead take it on faith that the calculations are happening - or not, as this gives an opportunity to describe compiler optimization. And of course, this is an opportunity for the student to practice thinking abstractly :)

This I completely disagree with—I have always found instant feedback to be immensely useful when teaching Caml programming. Instead of an act of faith about the calculations happening, I would rather have an act of faith about how "throwing things at std::cout" works.

Just a thought, but it would be interesting to see a tutorial that taught debugging practices along with language semantics. Instead of jumping into IO for instant visual results, or holding it off and having the student go on faith, you could teach how to step through a program in a debugger and verify that calculations are happening by watching variables, and things like that. I have no idea if this would work, or if debugging would go right over the head of a beginner (and, of course, it would make it pretty IDE dependant), but I think it would be helpful to instill good debugging practices right from the get go.

##### Share on other sites
Quote:
Original post by Driv3MeFar
Quote:
 Original post by ZahlmanWhen I had the idea of writing a book, I wanted to do two whole chapters before any code - the first on "what is programming" and the second on "what is C++", basically. And then in the chapter after that, I would build up the first "meaningful" program from simpler ones - starting with just 'int main() {}'.

So, when's your book coming out [grin]?

Good question [smile] I'll buy it.

##### Share on other sites
Since people have been mostly going over your general approach to the tutorial, I thought I'd point out some specific parts that I thought needed improvement.

2.1: "iostream and string are aptly named header files." At this point you haven't explained what a header file is.

2.2: I find it confusing when you talk about some values not being able to change, variables simply being names given to values, and that the value associated with a name can't be changed. After reading this I would think that making a variable called "i" with a value of 10 would be totally unchangeable. Because the value associated with a name can't change, it sounds like I couldn't do "i = 5". Because the value of the integer 10 can't change, it sounds again like I can't do "i++". This section needs revision IMO.

You might want to quickly explain that text in programing is called a "string".

I like your diagrams. They help reinforce what you've been saying and help get the reader 'in the right mindset' for UML.

[Edit: And maybe you should use the same syntax highlighting as VC++ does by default, since you're gearing your tutorial twords that IDE.]

I agree about not using Latin. I spent (wasted?) a good amount of brain power trying to recall if that was some phrase I knew.

That's all I've noticed so far (read up to 3.3). I'm interested as to how beginners will take your approach.

[Edited by - Ezbez on July 9, 2007 8:50:22 AM]

##### Share on other sites
If I may take the audacity to summarise several posts here: You assume too much that the reader knows the definitions of the terms you are using. For example, you don't even explain what "programming" is, and unless you're targeting these tutorials at people whom already know one or more languages, it's probably best you cover that, as even at that point there can be misconceptions. Other examples include (some taken from observation, and some raised in previous posts): "language", "source code", "execute", "header files", etc.

And I'll punch you in the throat if you take the easy option by tacking on an appendix of terms instead of a logical progression throughout the text. [grin]

That is all.

##### Share on other sites
Quote:
 Original post by Ezbez2.1: "iostream and string are aptly named header files." At this point you haven't explained what a header file is.

Changed to "iostream and string are aptly named header files (because they are mentioned in the header of the source code).

Quote:
 2.2: I find it confusing when you talk about some values not being able to change, variables simply being names given to values, and that the value associated with a name can't be changed. After reading this I would think that making a variable called "i" with a value of 10 would be totally unchangeable. Because the value associated with a name can't change, it sounds like I couldn't do "i = 5". Because the value of the integer 10 can't change, it sounds again like I can't do "i++". This section needs revision IMO.

Added some concrete examples using the assignment operator about how to modify a value. Perhaps I will add a chart as well.

Quote:
 You might want to quickly explain that text in programing is called a "string".

Quote:
 I agree about not using Latin. I spent (wasted?) a good amount of brain power trying to recall if that was some phrase I knew.

Added explanation of what the phrase means, along with a small bit of humor.

##### Share on other sites
Quote:
 Original post by _goatIf I may take the audacity to summarise several posts here: You assume too much that the reader knows the definitions of the terms you are using. For example, you don't even explain what "programming" is, and unless you're targeting these tutorials at people whom already know one or more languages, it's probably best you cover that, as even at that point there can be misconceptions. Other examples include (some taken from observation, and some raised in previous posts): "language", "source code", "execute", "header files", etc.

##### Share on other sites
Hi, I think I've found a syntax fault in your stylesheet file while learning from your code.

"http://www.nicollet.net/style.css":
body{  margin:                     auto;  padding:                    auto;  font-family:                verdana;  font-size:                  10pt;  width:                      1000px;}a{  text-decoration:            none;}a:hover{  text-decoration:            underline;}p{  width:                      600px;}/* ======================================================================== */div.code{  border-top:                 solid 1px #888;  border-bottom:              solid 1px #888;  background-color:           #EEE;  padding:                    3px;}div.code pre{  margin:                     0px;}div.code span.keyword{  color:                      #00F;}div.code span.special{  color:                      #088;}div.code span.literal{  color:                      #B00;}div.code span.comment{  color:                      #0B0;}div.code span.operator{  color:                      #888;}/* ======================================================================== */div.error{  border:                     solid 1px red;  background-color:           #FCC;}/* ======================================================================== */div.header{  width:                      1000px;  border-bottom:              double #888 3px;  margin-bottom:              3px;  padding:                    0px;}div.header img.logo{  float:                      left;  width:                      96px;  height:                     96px;  border:                     solid 1px #888;  margin:                     3px;}div.header h1{  float:                      left;  width:                      890px;  height:                     74px;  margin:                     3px;  font-size:                  36px;  font-variant:               small-caps;}div.header div.above{  float:                      left;  margin:                     3px;  width:                      890px;  height:                     20px;  font-size:                  16px;  font-family:                verdana;}div.header div.above img{  float:                      left;  margin:                     1px;}div.header br{  clear:                      both;}/* ======================================================================== */div.navigation{  float:                      left;  width:                      198px;               margin:                     1px;  font-size:                  12px;}div.navigation ul{  margin-top:                 1px;  margin-left:                0px;  padding-left:               3px;}div.navigation li{  margin-left:                20px;  list-style:                 square;}div.navigation li.category{  margin-left:                0px;  font-weight:                bold;  list-style:                 none;}/* ======================================================================== */div.see{  border:                     1px solid #888;  background-color:           #DDD;  font-size:                  120%;  padding:                    3px;  width:                      600px;  margin:                     5px auto 5px auto;}div.see div.desc{  font-size:                  75%;  padding-left:               20px;}/* ======================================================================== */div.content{  border-left:                1px solid #888;  float:                      left;  width:                      790px;  margin:                     1px 1px 1px -17px;  padding:                    3px 3px 3px 20px;  min-height:                 400px;  text-align:                 justify;}div.content h2{  margin-left:                -17px;  font-variant:               small-caps;  text-decoration:            underline;  font-weight:                normal;}div.content h3{  margin-left:                -10px;  font-variant:               small-caps;  text-decoration:            underline;  font-weight:                normal;}div.content h4{  margin-left:                -5px;  font-variant:               small-caps;  text-decoration:            underline;  font-weight:                normal;}/* ======================================================================== */div.footer{  clear:                      both;  border-top:                 double #888 3px;  text-align:                 center;  color:                      #888;}============================= */div.footer{  clear:                      both;  border-top:                 double #888 3px;  text-align:                 center;  color:                      #888;}888;}

The last bit here:
div.footer{  clear:                      both;  border-top:                 double #888 3px;  text-align:                 center;  color:                      #888;}============================= */div.footer{  clear:                      both;  border-top:                 double #888 3px;  text-align:                 center;  color:                      #888;}888;}

I guess that the bold last section shouldn't be.
div.footer{  clear:                      both;  border-top:                 double #888 3px;  text-align:                 center;  color:                      #888;}============================= */div.footer{  clear:                      both;  border-top:                 double #888 3px;  text-align:                 center;  color:                      #888;}888;}

Or is it valid? If so I want know how that syntax is,
but it doesn't look like it is.

Good tutorial BTW!

##### Share on other sites
Quote:
 Original post by programeringOr is it valid? If so I want know how that syntax is,but it doesn't look like it is.

It isn't valid. It's actually the result of me being utterly r0xx0red by ncftp. I've re-uploaded the file, and all is well now. Thanks for mentioning it [wink]

##### Share on other sites
Looks good, but I'd recommend changing "The C++ language is said to be strongly typed" to "The C++ language is said to be statically typed". Strongly typed, statically typed and typed are all often used to mean the same thing, but strongly typed and weakly typed are also often used to refer to sound vs unsound type systems. Under this terminology, C++ would be weakly typed and ML would be strongly typed. This might lead to confusion for the reader later. "Statically typed" is not ambiguous.

##### Share on other sites
Quote:
 Original post by RebootedStrongly typed, statically typed and typed are all often used to mean the same thing, but strongly typed and weakly typed are also often used to refer to sound vs unsound type systems. Under this terminology, C++ would be weakly typed and ML would be strongly typed. This might lead to confusion for the reader later. "Statically typed" is not ambiguous.

I'd tend to consider that the C++ type system is sound, as long as the user doesn't take explicit steps to disable the type system (using one of the various cast operators)—and if the existence of explicit type-system-avoding cast operations had an impact on the strength of a type system, Obj.magic would be a nasty blow to the (O'Ca)ML type system [smile]

I certainly take that strongly typed statement as a contrast with C being weakly typed.