The biggest problem I saw was that it introduces classes and objects but does not tell you anything about the "rule of 3", destructors, copy constructors and assignment operators. These are crucial to understanding C++'s pass-by-value semantics and writing sensible C++. C++11 adds to this mess by adding rvalue references, move constructors and whatnot. Writing good and safe C++ requires you to use stack based resource management wisely and use ctors/dtors for initialization and cleanup (this is also why you almost never write try/catch in C++ - and there's no finally statement).
Another example: the article shows you how to do a Java-like constructor like this: point::point(int x, int y) { this->x = x; this->y = y; }
When in C++ you want to use initializer lists like this: point::point(int x, int y) : x(x), y(y) {}
At best this tutorial teaches you to write "C/C++" (the worlds most popular programming language that does not exist) or "C with classes". This style of programming has all the disadvantages of writing C but none of the advantages of C++.
C++ is one of the most complicated languages out there, on par with Haskell and Scala. It's C legacy makes it also somewhat dangerous and the pass-by-value semantics make it very different from any other language out there. You cannot expect to learn even a little bit of C++ from little vague blog posts like this.
If you want to learn C++, buy a book! The web is full of crappy resources like this one.
It seems that with that in mind, coupled with the recent surge of people working on systems languages (Go, Rust, D) that people are looking for a something else. It'd be neat if we could resurrect Stroustrup's orginal prototype of C++ that was literally "C with classes". I wonder whatever happened to that...
I'd much rather see somebody take a crack at a new systems language that put generic programming front & center in a cleaner context.
unfortunately, there didn't seem to be a really good one.
The book is getting old but I still find it valuable and he builds up from C and teaches a whole lot more of the gotchas than this article does.
Also grab a copy of effective c++ by scott meyers.
... Not that OOP was scary. I had done Object Pascal years before (89). C++ had too much un-essential complexity.
In fact, if you are learning C++, you better start it as a new language, rather than a tumor grown on the side of C. These languages are too idiomatically different.
My strategy for writing in C++ is to write in C until I suddenly think "Hey, I should totally use an object here!"
http://www.boost.org/doc/libs/1_47_0/libs/smart_ptr/enable_s...
My C++ code is typically 3X shorter than corresponding C with fewer bugs and faster performance. The main issue is avoiding memory corruptions and getting away from pointers and memory leaks by leveraging the STL heavily.
I do use objects and make sure the members are C++ types rather than some C-style pointers, so that the copy and equality semantics are well defined. The key thing for me is avoiding pointers at all costs as pointers complicate memory management immensely. Use STL vector, set etc and in the worst case smart_ptr.
template <class ttype>
ttype multiply(ttype a, ttype b)
{
return a * b;
}
int * int doesn't always fit in an int. C++ Templates: The Definitive Guide suggests using a traits class to solve problems like this. Templates are a complex subject in general, and I wouldn't recommend using them without having read the aforementioned book.And yet every programming language that I can think of returns an int when you multiply two ints, and we get along (mostly) just fine. Did you have a better option in mind for that bit of code?
I mentioned C+++ Templates: The Complete Guide - it demonstrates a similar template (15.2.4) to add two values, and even with simple addition it points out a flaw similar to this one (and admittedly more likely to come up in the real world) - determining the return type for, say, int + char. Their solution is a traits class with a specialization for each pair of types. Sounds complicated, but then again, so is writing a template function to perform simple multiplication.
http://lwn.net/Articles/249460/
p.s. best comment in defense of the original poster so far has been by Shin Lao.
p.p.s the tut was targeted for a very specific audience + purpose. It was not purporting to be Bjarne Stroustrup's next meditation. Folks can offer support to another community member _ without _ being mean.
I would hope they continue & polish any rough edges in the material they've already got, however I agree that instead of nitpicking it to death we should be supportive of the author.
This is really nice work.
Someone doesn't understand the value of the "struct" keyword:
https://github.com/torvalds/linux/blob/master/Documentation/...
The example is also not very useful and even a bit perverse: sure you don't know what "vps_t a" is at first sight, but with "struct virtual_container a" you have almost the same information. If you could omit the "struct" and wrote it as "virtual_container a", the meaning is equally clear.
Anyway, I think this is a matter of taste.
const methods - if you declare a const rectangle r, you can't call r.surface() unless it's declared int surface(void) const {....
references - article seems to be confused why they exist. They enable some extra handy features, e.g. you can pass a temporary to a function parameter taking a const reference. e.g. you can pass f(MyClass()) if it's declared void f(const MyClass&), but not if it's declared void f(const MyClass*).
STL - things like std::string, std::vector, std::map - totally invaluable!
And lastly, the fact that programming in C++ is completely different to C. It's not like C with bolted on features. It's a whole new paradigm. For example, in modern C++, you very rarely have to manage memory. Smart pointers and containers can generally manage it all for you.
That would normally be about a chapter per-paragraph in most C++ resources around. Well done :)
Kudos!
http://news.ycombinator.com/item?id=3114374
I second 5hoom's additional attribute that you have demonstrated.