Thread: New C++ tutorial for beginners - opinions wanted!

Here is what I wrote about the concepts. It got quite long, so I covered only the most important ideas:

This tutorial is about learning computer programming. More precisely, it is about learning computer programming in imperative paradigm. Unavoidably, one imperative programming language had to be chosen, and given the contents of the tutorial it was determined that the C++ language would suit the best.

The tutorial is written in programming by examples style, i.e. it is example-driven.

In my experience, the hardest thing for a beginner to learn is NOT the programming language. Certainly, a beginner is going to make a lot of mistakes at first. But, most of those mistakes will be trivial and they will generally be caught by the compiler and reported correctly. Most today’s compilers are able to make comprehensible error reports. At the worst, when a beginner makes a mistake and doesn’t know how to fix it, he will ask about it on a forum, and there he is likely to get a prompt and correct reply, since the mistake is likely to be trivial.

The hard thing to learn about programming is how to perform and organize the desired computation. This is the thing that experienced programmers take for granted – how to skip every third input value, how to select only values with some property, those are the toughest issues a beginner will face. Those problems can be perceived as a kind of simplistic algorithms, and the beginner’s problem is: how to write them down in the imperative programming style.

Therefore, learning programming has very little to do with learning a programming language. The detailed description of the syntax and effects of statements is unnecessary and confusing for a beginner. He will easily pick up the syntax from the examples by himself without need for any extended explanations. It is sufficient to sporadically provide some hints on some elements of the syntax, in places where he is likely to make a common mistake.

Instead, the explanations should concentrate on structure of the program and extremely simple ‘algorithms’ (perhaps it would be better to say that those are simple tasks). For example: how to add up numbers, how to find a minimum value, how to count values with given property. There should also be some advice on how to organize the computation (functions help a lot there), and how to analyze and understand the given problems.

Therefore, the features of the language are to be explained only as necessary for solving concrete problems (where it would be ideal to introduce a new feature of the language just before solving a concrete problem using the feature). There is no need to go into extensive details about language features. Use the abstraction instead!

There is absolutely no need to explain features of the language grouped by their language category (for example, don’t explain in a single chapter all kinds of loops that a programming language provides). Not only that there is no need for such groupings, but they are inherently bad. Even more, a complex feature of a language can be explained in several parts, through several chapters, each time giving more detailed information, as necessitated by example programs. It is easier to learn complex features and concepts when they are broken down into more easily digestible bites, supported by examples!

In summary, when explaining computer programming to a beginner, you should be explaining computer programming more, and explaining the concrete programming language less.

Elysia:

I'm assuming the Visual Studio because the instalation of Visual Studio and project setup was explained in chapter 3:

Installing an IDE | Learn Programming with C++

Creating a Project | Learn Programming with C++

But you are right, on other IDEs the error you mention wont be caught. In fact, the issue is even worse that that (for example: Code::Blocks on Windows cant catch SIGTERM because Windows has no Unix signals). So I will certainly do something about it.

Thank you for catching that issue.

I would agree with you that beginners should use only checked array indexing, but using at() is problematic for other reasons (ugly syntax, wont work on gcc in Windows)

Compilers do implement it, but on IDEs which lack the ability to catch this error the program will just terminate. Therefore the feature is of little use for demonstrating the error, which was the purpose of the chapter in question.

"Ugly syntax" is subjective, but the number of characters isn't. Two characters for [], 5 characters for .at() .

You have some point there on stable code being more desirable, but I don't see any better way to fix this issue? The only way is providing a pach in the vector template, so that it calls the assert on out-of-bounds when some tag is #defined, and then to also fix assert to throw a signal which can be caught on all OS-es. That would not be against the standard.

I have added a note in the tutorial. That seems to be the best thing to do:

Index out of Bounds | Learn Programming with C++

Compilers do implement it, but on IDEs which lack the ability to catch this error the program will just terminate.

What ? Exceptions are not meant to be caught by IDEs but in case you're debugging on one ,the exception with probably be passed to the IDE.

A perfect example using gcc, with no IDE.

Code:

#include <vector>

int main()
{
    std :: vector<int> v;
    int a = v.at(6);
}

Output when program is run

Code:

terminate called after throwing an instance of 'std::out_of_range'
  what():  vector::_M_range_check: __n (which is 6) >= this->size() (which is 0)
Aborted

Silly me. I was working with Visual Studio for too long and wondered yesterday why nothing shows up when running a program in Code::Blocks with a debugger.

Yes, about exceptions, I was actually talking about raising a signal. Without it the debugger can't catch the error before the program terminates, so the IDE can't mark the source code line where the error occured.

Well, defining _GLIBCXX_DEBUG seems to solve this inconvenience with operator [] in Code::Blocks, so that is great. And there seems to be no need to use the .at() member function in that case.

The issue of performance would really be overwhelming so early in the tutorial. The performance considerations are not for beginners, although the tutorial will be talking about performance in some later chapters, where there is also a mention of Debug and Release configurations in Visual Studio. At that point the readers can also be instructed to remove _GLIBCXX_DEBUG if they need more performance.

I also have one more issue with Code::Blocks and gdb on GNU/Linux (more precisely, Ubuntu and Mint). The problem is that, in default installation, it seems not to show the elements of vectors (something seems messed up with pretty-printers). It would be necessary for the tutorial that Code::Blocks shows elements of vectors and of vectors which are members of structures and classes (one level deep, no more). I was thinking of asking about this in this forum, in some other topic...

You are right that it would be silly to attempt to handle all the possible compiler/STL combinations. But this is not a tutorial about C++, and I'm free to restrict the choice of IDE and compiler for the purpose of teaching programming.

Why can't you accept that there can be programming tutorials that are not about C++ language? Besides, I have already accepted some suggestions.