New C++ tutorial for beginners - opinions wanted!

Quote:

---

It is out of the question.

---

O_o

Yeah! You idiots need to stop being so close minded.

The view Kevin C has is the right one. End. Of. Story.

Soma

Quote:

---

Originally Posted by Kevin C

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.

---

While I think online tutorials tend to be language feature based, books are no stranger to an example-driven approach or to a focus on problem solving with programming rather than on the programming language itself.

For the former in C++, I suggest that you read Koenig and Moo's Accelerated C++: Practical Programming by Example, which was written based on material used to support a "professional-education course at Stanford University" and adopts a high level to low level approach similiar to the one recommended by Stroustrup in the essay that I linked earlier. The material is a bit dated post-C++11, but that does not matter since you are interested in the pedagogical approach.

For the latter, refer to Abelson and Sussman's classic Structure and Interpretation of Computer Programs. It uses Lisp and was designed to support a far more technical and demanding introductory computer science course at MIT, but it is a classic precisely because it has less to do with the intricacies of Lisp and more to do with computer programming and computer science.

Thanks for the suggestions! I watched the "Structure and Intepretation of Computer Programs" videos, and I think that it is really marvelous (although it is for MIT students, not for beginners). And I did already look into Accelerated C++, and many other materials, but I will certainly take another look into Accelerated C++.

Quote:

---

Originally Posted by Kevin C

Ok, that covers many examples. But I think that using operator [] instead of .at() in tutorials and books is quite common. Perhaps you could point to me to some other reputable tutorials or books that employ the .at() operator so early and often to be in accordance with your suggestion.

Edit: If that is such an indispensable best practice, I expact that most other tutorials and books are employing it,too.

---

Bjarne Stroustrup's Programming Principles and Practices using C++ uses range checking from the beginning of the book by including it in a header file.

Code:

---

template<class T> std::string to_string(const T& t)
{
    using namespace std;
    ostringstream os;
    os << t;
    return os.str();
}

struct Range_error : std::out_of_range {    // enhanced vector range error reporting
    int index;
    Range_error(int i) : std::out_of_range("Range error: "+to_string(i)), index(i) { }
};

// trivially range-checked vector (no iterator checking):
template<class T> struct Vector : public std::vector<T> {
    typedef typename std::vector<T>::size_type size_type;

    Vector() { }
    explicit Vector(size_type n) :std::vector<T>(n) {}
    Vector(size_type n, const T& v) :std::vector<T>(n,v) {}
    template <class I>
    Vector(I first, I last) :std::vector<T>(first,last) {}

    T& operator[](unsigned int i) // rather than return at(i);
    {
        if (i<0||this->size()<=i) throw Range_error(i);
        return std::vector<T>::operator[](i);
    }
    const T& operator[](unsigned int i) const
    {
        if (i<0||this->size()<=i) throw Range_error(i);
        return std::vector<T>::operator[](i);
    }
};

#define vector Vector

---

So when you type foo[x] then you are already implicitly using range checking.

Putting such things in a custom header file means that your learners already are using range checking from day 1 without having to do anything. Understanding the header file code is not even necessary, but of course later on you need to say "Okay now open up the header file and read how this stuff really works."

Strange. In the version of Stroustrup's Programming that I have (2009), vectors are first introduced at the page 116. He uses them the same way as I do, with the operator[].

Stroustrup is very knowledgeable about the C++ language, but I think that he is not a good educator at all. Just look at the structure of his book. He is explaining so many features and details about the language, so he is not able to produce a good example program in the first 250 pages. He is so incredibly slow and just overloads the reader with mountains of unnecessary information. I doubt that there is a single true beginner who was able to learn programming just by reading his book.

So Stroustrup, for me, is not quite the best reference when talking about good tutorials.

Quote:

---

Originally Posted by Kevin C

Strange. In the version of Stroustrup's Programming that I have (2009), vectors are first introduced at the page 116. He uses them the same way as I do, with the operator[].

---

Assuming that c99tutorial's code snippet is taken directly from the library provided with the book, then the vector that the student initially uses is not std::vector, but rather a derived class template disguised as vector as can be seen by:

Code:

---

template<class T> struct Vector : public std::vector<T> {
// ...
#define vector Vector

---

This would normally be a pretty dastardly thing to do, but I guess he decided to excuse himself on the grounds that this will simplify for learning and later the student will learn the real std::vector anyway.

Yes, but that sides with what I was arguing for.

Look more closely in the last few pages what the argument was about.

Quote:

---

Originally Posted by Kevin C

Yes, but that sides with what I was arguing for.

---

No, it doesn't: you were arguing for the use of the overloaded operator[] of std::vector, not for the use of an overloaded operator[] for which a range check is guaranteed regardless of standard library implementation and compiler options. Rather, it is a compromise solution as mentioned by jimblumberg in post #68 (with reference to the same book by Stroustrup).

Personally though, I dislike Stroustrup's extended library solution: it introduces a small barrier to online help in that you need to know the book or the help seeker needs to provide more information.

In my opinion, the argument was whether to use operator[] or .at() member function. I'm all for operator[]. The exact details are of less interest to me, but it seems to me that my version is easier for a beginner. I don't see much difference whether range checks are instituted this way or another.

Perhaps you should be interested.

This is your current alternative from the black and white on the page:

Quote:

---

If you are using Code::Blocks IDE, the mentioned dialogue will not be displayed. In fact, the C++ language standard does not require this error to be caught, but the Visual Studio will catch it when running in Debug mode (but not in Release mode). In order to see this error in Code::Blocks, from the main menu choose Settings->Compiler, and the Global compiler settings dialog will open. Somewhere in the middle of it there is a tab titled #defines. Select it, and then add the line containing the text _GLIBCXX_DEBUG there. Then click the OK button. From the main menu, choose Build -> Rebuild. Then choose Build -> Run.

---

These are fairly complex instructions and the path of least resistance is to just not do this. Meanwhile, the problem of out of bounds access will persist. I would think that any option that is guaranteed to work without the reader doing a particular thing - whether it is using at(), or a specialized version of a container that implements operator[] bounds checking - would be palatable to you.

You are depending on a particular error appearing in order to train people to spot this problem. In reality, with none of these protections active, a segmentation fault may occur, crashing the program. The proper response then is to enter the debugger, step through the code, and find then fix the code that triggers it.

Quote:

---

Originally Posted by Kevin C

In my opinion, the argument was whether to use operator[] or .at() member function. I'm all for operator[]. The exact details are of less interest to me, but it seems to me that my version is easier for a beginner. I don't see much difference whether range checks are instituted this way or another.

---

No, the argument was whether to use the overloaded operator[] or the at() member function of std::vector. This difference is critical for you because it means the difference between having to instruct the reader to deal with the possibility that the standard library implementation does not have checked iterators turned on by default or perhaps does not have such a feature at all, and just going with the flow because the range checks will always happen.

If operator[] had the range check guaranteed, then you certainly would not have the objections here because they were all about the range checks.

I wouldn't say that those instructions are complex. Besides, what's the alternative? Adding a library file to search paths of Code::Blocks is likely to be more complex.

The tutorial is for beginners. They are given very specific instruction, so they will be working either on Visual Studio 2013, or on Code::Blocks 13.12 (GNU C++ Library). The possibility that they are using something else is almost zero. In that case they won't get the error report (that is not so terrible).

About the original argument, I can agree that this is some kind of addition to original argument, which is OK.

Anyway, if we are now debating whether it is better to use plain std::vector, or some custom vector class replacing it so that the range check is guaranteed, then I should also present my opinion and arguments about this issue.

So, if a custom vector class is used, then there could be some problems if it doesn't replicate entire functionality of std::vector. The writer of this custom class has to be extremely careful and do some not-insignificant work to closely mimic the behavior of std::vector. There could be some compatibility problems, due to GNU C++ library being updated.

This custom vector should be available through a custom header file, and the beginner needs to be instructed to #include this header file in his programs. There could be some problems if he forgets it, or if he forgets it only in some source files of a program, or if he copy-pastes some code from the Internet which includes std::vector.

Also, it should be explained later in the tutorial to the beginner that he should be not be including this custom header file in his future programs so that he can share his code more easily, and also that this custom header file is a custom addition and that others may not know what it does. Furthermore when he doesn't include this custom library, the range checks will not be performed.

Well, looking at this, it seems to me that my original approach is more clear, simpler, and likely to produce a smaller number of problems.

And also, there is a benefit of my original proposal with _GLIBCXX_DEBUG that the reader will learn about a nice feature of GNU C++ library, which can certainly come in handy.

Quote:

---

Originally Posted by Kevin C

I wouldn't say that those instructions are complex. Besides, what's the alternative? Adding a library file to search paths of Code::Blocks is likely to be more complex.
(...)
This custom vector should be available through a custom header file, and the beginner needs to be instructed to #include this header file in his programs. There could be some problems if he forgets it, or if he forgets it only in some source files of a program, or if he copy-pastes some code from the Internet which includes std::vector.

---

From what I see from posts by Osman Zakir who is apparently going through that book, Stroustrup provided one or more header files along with the book, then instructed readers to just copy the header(s) to the same place as the source files that the reader creates. This sidesteps having to fiddle with include paths.

Curiously, I notice that the header available online is named "std_lib_facilities.h", whereas Osman Zakir included "custom_std_lib_facilities.h" and at one point also included <vector>, so maybe at some point the book instructs the reader to create their own version of the header without this particular vector hack.

Quote:

---

Originally Posted by Kevin C

So, if a custom vector class is used, then there could be some problems if it doesn't replicate entire functionality of std::vector. The writer of this custom class has to be extremely careful and do some not-insignificant work to closely mimic the behavior of std::vector. There could be some compatibility problems, due to GNU C++ library being updated.

---

Stroustrup avoided this problem entirely by using public inheritance. A caveat is that std::vector is not designed to be a polymorphic base class, so his solution is arguably a Bad Thing (even without the macro that he admitted is disgusting).

Quote:

---

Originally Posted by Kevin C

Also, it should be explained later in the tutorial to the beginner that he should be not be including this custom header file in his future programs so that he can share his code more easily, and also that this custom header file is a custom addition and that others may not know what it does.

---

Agreed. This is related to my complaint that it makes receiving online help more difficult.

Quote:

---

Originally Posted by Kevin C

Furthermore when he doesn't include this custom library, the range checks will not be performed.

---

True, but then the only long term solution to this to use the at member function consistently, which as I noted earlier seems overkill to me in situations where the iteration over the range is obvious, and which you are clearly against. That said, post-C++11, one could argue that in such cases the range based for loop could be used instead, eliminating this issue entirely.

Quote:

---

Originally Posted by Kevin C

Well, looking at this, it seems to me that my original approach is more clear, simpler, and likely to produce a smaller number of problems.

---

Looking at your revised page, it looks like you clearly mention in a side block that "In fact, the C++ language standard does not require this error to be caught". I do not recall if you had it there earlier, but as it stands I'd say that it looks satisfactory in terms of correctness.

Quote:

---

Originally Posted by Kevin C

And also, there is a benefit of my original proposal with _GLIBCXX_DEBUG that the reader will learn about a nice feature of GNU C++ library, which can certainly come in handy.

---

You could mention this either way: checked iterators, as the name implies, goes beyond merely enabling a range check for the overloaded operator[].

Another suggestion: use braces even when unnecessary. This can avoid dumb mistakes related to scope even for experienced programmers, so one might as well start beginners off with this habit.