Why You Should Know C++
unknownprogrammer.com
unknownprogrammer.com
In fact, I am sad to say that unless your job requires it, I can't really think of any reason to learn the language. It relies on a mixture of paradigms that are easier learned from other languages where they are isolated. And for lolevel stuff, you are better off learning C.
All serious development frameworks nowadays for desktop applications are either C++ or Objective C. Most native libraries are one of the two. Even the driver SDKs are mostly build on an object oriented approach.
And learning C++, you will know C. Your opinion is a popular opinion among web developers and people who do not do desktop development, but in the real world, it has a lot more advantages to learn C++ instead of C.
Sure, if you know C++ well, you'll be able to do C, but learning C++ is that much harder than C, that it's often not worth the effort. You'll be able to interface with most libraries once you know C, even if you use any other language as your primary tool. Learning C++ won't give you that much extra.
You seem to be locked down by a particular perspective on software development, and this is unfortunate.
That's utterly untrue. The low-level details of C++ are mostly the same as C's, unless you want to write a shared library in C++ and thus need to extern the C++ symbols, or need to worry about the details of the object-system implementation like vtables, or need to mess with streams and layer them over some communication medium.
What makes C++ fucking hard is the syntax explosion that feels like cleaning up a New Year's Eve confetti with your bare sweaty hands, the template voodoo, and the design patterns that they have tacked on the language to make it more palatable to Satan.
To make it worse, the language is both broad and deep. You can't learn C++ by reading the standard. You have to dip into the culture of one of the big vendors, or schools of programming, to find out what subset of the language is to your liking. Are you writing Bjarne's C++ or GoF's or Alexandrescu's? or perhaps you would prefer to old HP/STL/Meyer C++ to the new kitchen-sink BOOST C++?
Contrast this to Common Lisp, which is a very broad but relatively shallow language; you can read the first few sections of every chapter of the manual and come off a good Lisper, go back and dig deeper and you only get better. OO, functional and procedural Lisp looks relatively the same. If you don't understand a construct, you look up the documentation of the symbol, see its evaluation model and presto. C++? You don't see what's being implemented because higher-level designs are being kludged and modeled with dickish, brittle and contrived tools -- they have no way out of this, as the language insists on C pseudo-similarity and refuses to adopt any kind of clean macro system; they're running out of syntax and CPP is unforgiving. Understanding C++ code then becomes a matter of psychological profiling of the author and even scholarly exegesis and deconstruction ("What did he intend to say?", etc.) requiring a level of empathy hard to muster when you're, in fact, wishing ill and misfortune on the bastard who forced you to look at this mess.
I agree that C++ is very library oriented, and it changes your approach to the language, but this is not a fault of the language itself, this is a side-effect of its very wide popularity.
If you have a pattern used by a library, then that is the fault of the library, but not a fault of the language. The language does not come with any patterns.
Templates in C++ are not good, but they are not widely used in the real world. Most people ignore them, and that's good so.
Depends on where your "real world" is. C++ usages are vendor and library dependent. My C++ code looked different in MFC/COM/ATL than in FLTK and that too was different than Qt. Choosing the right C++ becomes a matter of choosing the right vendor, and if that choice isn't up to you, well, tough luck.
You can use Objective-C as a datapoint here. That's Smalltalk on top of C. You can use the same sort of trick (delimiting the dynamic sends) to recycle the C keywords in the dynamic context, and end up with a language with just a few more keywords than C.
The reason is simple: They are difficult to understand. Code is communication, and there are two listeners - and when you are pushing function pointers around using macros, the human is going to have huge problems understanding what you are trying to achieve.
So I don't think exploiting particular features of a language to extreme levels when it is unneccesary makes you a good programmer in that language - I actually think it makes you worse.
It's like writing a book - you have a certain vocabulary at your disposal, and you can say almost anything you want with that vocabulary. There are different levels of obscurity in the words you use you can reach - you gain in expressiveness, but you narrow your audience. When you write a book for molecular biologists, then the particular terms you use should not be the same as when you write a biology textbook.
That's why I think that one can be a good C programmer without going much deeper than the C subset commonly used in C++.
This is part of my general philosophy in programming - clarity, simplicity and structure first, efficiency second. The machines will catch sooner or later, anyways.
C++ has templates, so you don't need to do as much with macros. C++ has virtual functions and overloaded operators (allowing for functors), so you don't need to do as much with function pointers. Structures can have methods in C++, so the way that you'd set up an opaque type is quite different in C++.
C++ also has about 10000 other features as well though, which is what makes it unwieldy to learn. The patterns mentioned above aren't about efficiency; they're about encapsulation.
Just to give an example -- in C++ if you want to set up a callback, for example with an observer pattern, you'd use a pure virtual function (and then pass in a concrete instance of that class) or a functor. You can't do that in C, so you use a function pointer. You learn to work with function pointers more because they're a necessary part of designing C APIs, whereas they're not in C++.
(Note that it's the language I'm best at, followed by C, so this isn't random C++ hating.)
I'm not saying there are no good reasons to learn C++. Just don't think that you'll really appreciate C until you've actually used it all by itself (with maybe a few C++isms here and there like //comments).
I went from C++ to C# and wouldn't want to go back, but C++ is still a strong and lively language with many active projects and a good future. If I would be forced to implement something outside the .net framework, I would not hesitate to pick it up again.
To do low-level C++ you'll have to learn low-level C anyway and learning C in and out is a far easier endeavor than learning C++ in and out. So if you're wanting to dip into low-level stuff, you need to learn at least C and may want to learn C++ as well.
(More generally the above does not hold -- the way you approach and solve problems in C and C++ does vary a good deal in higher-level stuff, but if you're doing bit-wrangling, you do tend to end up with something that approximates C bunched into classes.)
Point 1 tacitly assumes that learning C++ not only teaches you a common subset of many other popular languages, but also is the easiest way to learn said subset. This is wrong: a lot of simpler languages can teach you the same, e.g. JavaScript or pre-1.5 Java.
Point 3 says a given code sample in the wild has higher probability of being in C++ than any other language. This clashes with my impressions.
Point 4 assumes that the main difficulty of C++ is due to pointers and manual memory management, and that knowing your way around those issues will help you in other programming areas anyway. This sounds wrong to me: C shares those "difficulties" with C++ and isn't generally regarded as a hard language. The difficulty of C++ mostly stems from design decisions unique to C++ and useless elsewhere, like template metaprogramming or the dangerous combination of manual memory management with exception handling.
Point 5 implies that C++ invented parametric polymorphism and that this facility is essential to make algorithms work on a variety of data types. Wrong on both counts: ML and Ada generics predate C++, and Smalltalk-like dynamically typed languages solve the same problem without type parameterization.
Point 6 assumes more libraries have C++ interfaces than C interfaces, which is wrong by an order of magnitude at least.
Point 9 assumes most programmers are more interested in performance-oriented and algorithmically complex projects. Can't give statistics here, but I'm a data point to the contrary: I love UI and frontend work.
Point 10 is valid.
My own reasons for knowing C++ are a combination of point 10 and the need to muck around with http://mapnik.org - the only C++ library I ever found useful. And its code sucks, I'd kill for a C/Python alternative.
Skip to http://yosefk.com/c++fqa/defective.html for a great overview. And if anyone ever mentions "templates" again I'm gonna smack them hard.
6. Libraries are more likely to have native C bindings than native C++ bindings.
Also this:
10. You will hardly be seen as a hacker if you don’t know C++
and this:
8. There will always (or, at least, for a very long time) be a niche for C++
Not just C++, but also learn C, Java, Perl, Python, Erlang, Lisp, PHP, Shell Scripting, Assembly, Ruby, along with their most used libraries/frameworks. The more diversify your skillets, the better you can use the right tool for the moment, improving performance of that, lower development time. (Eg. A spoon can be used to build a house, but it's hardly the best tool out there).
This way, want to hack up a quick content management or low computational front end system, whip out your php/python/ruby with your favourite framework out. Got a bottleneck at high cpu or memory bound place, rewrite that piece in C/C++. Need to deploy a cross platform app really quickly, Java. Want to bind or write a test for a bunch of tools, use Python or Perl. The list goes on.
Summary: Learn More, use the right tool, do less, get more accomplished.
(1) Other languages may be influenced by C++ (especially at a syntactic level, and, superficially, in their object models). But those other languages are far easier to learn and become facile with than C++ is. Point (1) advocates for learning languages in the wrong order.
(5) Templates and generic programming are just tools to mitigate the badness of C++.
(10) Though a majority of the smartest hackers I've worked with know C, a minority of them are C++ developers. And that still leaves plenty of room for smart people who know neither language.
Yeah right! You are "seen as a hacker" if you write code that is useful to others and/or is brilliant in some respect. Nothing to do with knowing a particular language.
If knowledge of a specific language is a criterion, I'd rather have someone be an expert in C/lisp/smalltalk/haskell/prolog.... C++ originates or embodies no concepts that weren't discovered or done better elsewhere.
e.g: An expert smalltalker is more likely to understand OO than a C++ programmer.
I could learn C++, or I could learn Smalltalk, Scheme and Haskell in the same time and mental space.
Things like single line // comments and not having to declare all your variables at the top of your functions is really useful.
STL is also really useful in that you don't have to (badly) reinvent basic data structures like vectors and maps. Of course, STL also means reading compiler errors that are pages long... :-/
Also on the data structures. Base C does not include them but there are libraries for such data structures if you want such as glib.
I find my time is much better spent writing in a more flexible language that integrates well with C (I like Lua), and saving C for the small parts that actually need it. Also: I can think of few language that have worse object systems than C++. It's not exactly a shining example of OO done right.
Often, an efficiency issue is better remedied by a fundamentally different design, rather than just "pushing harder", and C++ makes it particularly easy to lose sight of this.
About the idea of C++ as a better C, See "C++ - The Forgotten Trojan Horse". (http://ejohnson.blogs.com/software/2004/11/i_find_c_intere.h...)
If you're using C++ for the STL, keep in mind that the ML languages (OCaml, SML) also have compile-time parametric data structures, and they infer and check their usage for you.
They also have a proper module system, so when you change a private variable, you don't have to choose between linking errors or recompiling damn near every piece of C++ code in your source tree.
They're also pretty fast.
It's the difference between C's qsort and C++'s std::sort. The latter blows the former out of the water when sorting small things. This brand of polymorphism is unique to C++ and until someone does it better (which no one seems to have any interest in, except maybe Walter Bright) then C++ will always be "the best C."
Seriously, the defining aspect of most programming competitions is that you're making a program as fast as possible, whatever it takes. C++ rewards this: if you keep sinking an order of magnitude more effort into it, you can seemingly always shave off another tenth of a percent of the time. There are some cases in which this is actually relevant (many involving graphic rendering, a niche I work in, PS), but they're really a tiny part of programming.
It makes sense to code them in C++ (or C), but it's really not the best fit for more general development, which usually places a higher priority on being able to deliver an adaptable and correct solution.
( Disclaimer : My comments are limited to only the above 'popular' languages in discussion. Also I program purely on *nix, so I am not aware of your other dark or better worlds out there )