I realize the guy thinks "object oriented" too much. IMHO 2009 C++ is tailored for generic programming and meta programming. If you try to do C#/Java in C++, yes, you're going to bleed.
C++ is a multi-paradigm language, but it shines when you go generic. You can do incredible things.
And then I stumbled upon this:
"For example, overloaded operators have to return their results by value"
Wrong. The author doesn't understand the difference between, value, reference and pointer in C++. He doesn't understand copy elision. He doesn't understand operator overloading as well and when he talks about smart pointers he says you have to rely on defective (?!) meta programming features (?!). How, I thought I simply had to use std::shared_ptr.
C++ is hard. Because it's made to solve very hard problems.
And yes, you can solve these problems in C, you can also solve them in assembly while you're at it.
C++ bad reputation comes from people who should never have been in contact with the language in the first place.
"C++ is hard. Because it's made to solve very hard problems."
What the hell does that mean? If it's Turing complete, it'll solve your hard problems. I don't understand how making a language inconsistent and obtuse makes it a good tool.
So you spend a year figuring out all the gotchas that will make you leak and corrupt memory. Great, now it's time to start getting some work done!
IMHO 2009 C++ is tailored for generic programming and meta programming
That was not the design goal and it was not how C++ was marketed by Stroustrup or anyone else. You cannot shift the blame onto people that are using the language as it was intended and marketed. The blame lies with C++.
That it seems to be perfect for generic and meta programming is nice, but an unintentional side effect. However, what use are generic and meta programming without a sane range of 'regular' programming capabilities?
C++ is marketed by Stroustrup as a multi-paradigm programming language and this was its design goal from the beginning. Generic programming was a design goal, not a side effect.
Regular programming capabilities are abundant with the CRT and OOP.
The fact that it happens to be perfect for generic programming is pure chance. It could have been botched like many of the other features. It had too many design goals, that is part of the point.
It is not abundant with regular programming capabilities: the main point of the arguments against C++ is that the regular capabilities are infested by problems from the more advanced features. Marketing something as multi-paradigm language implies that you can also use it for plain and simple things. Hell, you can even use Java for simple things. The post I responded to denied that. You are simply trying to prove my statements incorrect, without looking at the context in which they were made: the parent post and the specific sorts of criticism leveled against C++.
what use are generic and meta programming without a sane range of 'regular' programming capabilities?
C++ contains C. How can it not contain a sane range of 'regular' programming capabilities?
(Of course in this context, 'regular programming capabilities' does not refer to web apps so let's just avoid that whole argument and take for granted that C is a useful language.)
This is a great instance of two (maybe 3) arguments against C++ canceling each other out: On the one hand, C++ sucks because it's wed to C and inherits all it's legacy warts. Anyway, C is a better C++ because it's simpler. And yet, as you claim, C++ offer's no useful core of functionality on which layer all the generic templately goodness.
Unfortunately, you cannot just use C++ as if it were C, because some of these FQA's will still trip you up. The point of this FQA and other recents C++ criticisms is that you have to choose a specific subset and still be wary of all 'unexpected' things that happen in that subset.
You should've noticed three things before writing it:
1) His background is C++/Embedded.
2) He does that successfully for a living.
3) He really knows what he's talking about.
This leads me to a conclusion: Maybe the subject of your last phrase is YOU?
I also don't know what yosefk means when he says that smart pointers rely on defective meta-programming techniques. The implementation of Boost's smart_ptr doesn't seem too esoteric to me.
So is this how "appeal to authority" works in language pissing contests? The "authority" is money? "I make money using this language so blah blah blah QED."
Just one language? Of course not that's selling yourself short. Surely, with great effort and many years, you can master many languages, and use them masterfully in concert like many do with C and Python. And if you can do that then you can master the many faces of C++. Maybe you just don't need to.
Who knows, I'll rather use a mixture of languages than C++. C combined with other languages will suffice for now, as most of them are simple enough to understand entirely.
What is the point of making this almost religious? Ok, C++ sucks. Now what? I know it's shocking but you will find similar criticisms for any other language out there. Just keep an open mind and use the right tool for the job and circumstances at hand. Sometimes it may be something you are uncomfortable with. Do you want to be a programmer or do you want to be a java/c++/python programmer?
As soon as someone bashes a programming language, people start shouting "use the right tool for the job" and, most of the time, I agree. However, I think that is only true if the language really is the right tool for any job. I'm not sure C++ is ever the right tool. And when C++ is a decent tool for the job, it is only with significant policy reducing its feature surface area.
The two areas were C++ is strongest are actually better handled by C or by a combination of C and a higher level language....
Systems programming: C code is more predictable; less place for bugs to hide. It also better represents the underlying execution model.
Performance critical applications: C offers a standardized binary interface to implement performance critical components with effective interop for business logic written in higher-level languages.
That's not to say that C is the be-all, end-all systems or performance language. It's just better suited to the task than C++. Writing an entire application in C OR C++ is almost never using the right tool for the right job.
I agree with jacquesm--see the humor, but take it as cautionary. I did 12 years of C++ and it helps to take the 20% cut. If you look at google's coding standards you can see the restrictions that they put into place.
Few modern languages get as much criticism as C++, and I think rightly so. It is very complex, and takes way to long to master.
If you look at google's coding standards you can see the restrictions that they put into place.
Keep in mind, though, that reasons for many of those restrictions have to do with maintaining compatibility. This may not be as much of an issue with newer projects.
OTOH, Google's coding standards is probably the most thorough, well documented, clear, and easily available set of C++ coding standards out there. For this reason, I don't think it would be a horrible decision to use them for a new project.
I think it is actually pretty sane stuff in there and you can use it to your advantage when programming C++.
It's a pretty subtle kind of humor I think, but I don't think it is meant as a put-down, more an extensive critique from years of experience. You can't know that much about the shortcomings of anything if you haven't spent significant time with it.
"And you can also test your code by creating programs that check if it does what you want it to do in a bunch of cases. It's the same with C++ except that it compiles forever and you have to write notable amounts of code to implement the simplest test, so C++ code ends up being tested pretty rarely."
If I'm not mistaken, the person who wrote the C++ FQAs has a blog (http://www.yosefk.com/blog/) with some rather impressively technical content. He appears to have a fairly solid grasp of what he's talking about, and not to be some (e.g.) Python/Ruby/Perl/etc. programmer who hasn't written a line of C++ in the last five years but will gladly rail against it.
Why a post with only a link to a C++ FQA is that much high rated? Maybe I missed the point, but everyone with a bit of C++ knowledge already know that website. Suppose I post a FAQ on python, will it be top 10 ? I don't know, the author could have added a bit of explanation.
I figured it is an excellent distillation of what to avoid, and more importantly, why, written by someone with a lot more knowledge on the subject than most and in a style that I thought was quite humorous.
That last bit seems to have been received in a 'mixed' fashion judging by the responses.
Every time I tell someone about how marvelous the STL is I hear "yeah we have lists and maps in X language as well, C++ sucks".
The list I read in:
http://www.yosefk.com/c++fqa/defective.html
I realize the guy thinks "object oriented" too much. IMHO 2009 C++ is tailored for generic programming and meta programming. If you try to do C#/Java in C++, yes, you're going to bleed.
C++ is a multi-paradigm language, but it shines when you go generic. You can do incredible things.
And then I stumbled upon this:
"For example, overloaded operators have to return their results by value"
Wrong. The author doesn't understand the difference between, value, reference and pointer in C++. He doesn't understand copy elision. He doesn't understand operator overloading as well and when he talks about smart pointers he says you have to rely on defective (?!) meta programming features (?!). How, I thought I simply had to use std::shared_ptr.
C++ is hard. Because it's made to solve very hard problems. And yes, you can solve these problems in C, you can also solve them in assembly while you're at it.
C++ bad reputation comes from people who should never have been in contact with the language in the first place.