O_oIt is out of the question.
Yeah! You idiots need to stop being so close minded.
The view Kevin C has is the right one. End. Of. Story.
Soma
O_oIt is out of the question.
Yeah! You idiots need to stop being so close minded.
The view Kevin C has is the right one. End. Of. Story.
Soma
“Salem Was Wrong!” -- Pedant Necromancer
“Four isn't random!” -- Gibbering Mouther
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.Originally Posted by Kevin C
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.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
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++.
Last edited by Kevin C; 07-10-2015 at 02:06 AM.
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.
So when you type foo[x] then you are already implicitly using range checking.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
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.
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:Originally Posted by Kevin C
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.Code:template<class T> struct Vector : public std::vector<T> { // ... #define vector Vector
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Yes, but that sides with what I was arguing for.
Look more closely in the last few pages what the argument was about.
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).Originally Posted by Kevin C
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.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
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:
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.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.
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.
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.Originally Posted by Kevin C
If operator[] had the range check guaranteed, then you certainly would not have the objections here because they were all about the range checks.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
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.
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.Originally Posted by Kevin C
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.
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).Originally Posted by Kevin C
Agreed. This is related to my complaint that it makes receiving online help more difficult.Originally Posted by Kevin C
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.Originally Posted by Kevin C
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.Originally Posted by Kevin C
You could mention this either way: checked iterators, as the name implies, goes beyond merely enabling a range check for the overloaded operator[].Originally Posted by Kevin C
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.
Last edited by laserlight; 07-13-2015 at 11:14 AM.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)