Oh yeah, let's put Chromium, Firefox, and all of KDE on that list too.
As a person who is proficient in both C and C++, I find this constant war ridiculous. Neither languages are obsolete ok? Which one is best for you depends on the circumstances. Stop speaking in absolutes.
As for C it is a great language but it is pretty much only for either old stuff or system level stuff. In the real world I see people pick C++ over C if possible.
If you're doing any embedded programming you're going to be using C. C++ is pretty much exclusively used in the gaming industry, and there mostly because of historical reasons more than anything else (all the popular frameworks are written in C++).
I'm curious how you've come to that conclusion? C++ is used in most of the major web browsers, most of the major database engines, most of the major office program suites, it's widely used at Adobe, Microsoft and Google... C++ is in the top 5 of most language popularity rankings (TIOBE, langpop).
Sure, C++ has its issues, but claiming it's only used in one industry is way off base.
As for office suites, there's three of them out there, MS, which is C#, Apples which is ObjectiveC, and LibreOffice which so far as I know is Java.
I wouldn't be entirely surprised if a lot of the DB engines are done in C++, but I also would expect quite a few of them to be done in C as well. DB engine is a rather specialized area that demands the best performance you can possibly achieve, so something low level like C or C++ is to be expected. In order to achieve top performance you need to sacrifice ease of use so a really basic language like C or C++ is expected.
Interestingly enough looking at the source code for Firefox there is indeed some C++, but there's actually a lot more JavaScript in the Firefox source tree than there is C++.
On a closed-source project, it's hard to get the details. But the open source projects, however, we can get a very clear picture.
OpenOffice: [1]
10.4 million lines of C++
1.2 million lines of Java
*edit* noticed you mentioned LibreOffice, not OpenOffice
LibreOffice: [2]
5.7 million lines of C++
0.4 million lines of Java
Firefox: [3]
4.0 million lines of C++
1.8 million lines of C
1.7 million lines of javascript
MySql: [4]
7.0 million lines of C++
4.0 million lines of C
0.4 million lines of javascript
0.3 million lines of Java
> Most new development isn't done in C++
Whether or not C++ is the right choice for new development is a different question. Github posted their top 20 languages for new repositories in 2013 [5]. C++ is #6 and has more new projects than C, Objective-C and C#. Even if it's fading in popularity, that's still a lot of new projects in C++.
[1] http://www.ohloh.net/p/openoffice/analyses/latest/languages_...
[2] http://www.ohloh.net/p/libreoffice/analyses/latest/languages...
[3] https://www.ohloh.net/p/firefox/analyses/latest/languages_su...
[4] http://www.ohloh.net/p/mysql/analyses/latest/languages_summa...
[5] http://adambard.com/blog/top-github-languages-for-2013-so-fa...
Source: I work at Google and use all the languages in use at the company (including both C++ and Go) on a daily basis.
The answer to that question, IMHO, is yes which is what the OP wanted to know. Had they asked what languages they should learn I would put other languages above C++ but that wasn't their question :)
Maybe so, but the programmers I know who have switched from C++ to Haskell/OCaml/F# never seem to regret it. They are getting more done in less time, and spending a greater fraction of their time writing good software than tracking down annoying low-level bugs. The small trade-off in performance does not seem to be an issue, and in the few places where it is, some C or assembly code invoked via an FFI solves the problem.
"C++ is still one of the most flexible languages for application development"
Only if you are not counting the overhead of actually getting a complex C++ application to work reliably. Even the new abstractions in C++11 and C++14 seem to force programmers to deal with low-level issues than in almost every case are a distraction from the high-level problem being solved.
All languages make tradeoffs. You need to understand your domain and the tradeoffs associated with them.
It's likely that your idea of what is 'inherent' to C++ is just wrong. First of all, C++ is almost a superset of common C so, yes, it can can really replace C entirely and completely. Whatever grievances you have with the language don't change the reality that even embedded code benefits from, and has been gaining ground in, C++ for quite some time.
In any case, I'm not arguing C++ is inherently 'better' than C. I'm just saying betterunix's assertion that C++ is somehow 'legacy', and C somehow isn't, is weird and illogical.
We do still have a need for a low-level language; C is not the greatest language but it gets the job done. There is also quite a bit of C code out there, proof-of-concept code, reference implementations, etc., and so not knowing C means being cut off from all of that. C++ is not as commonly used for such things, or if it is then only a minimum subset of it is used, and it has no advantage over C as a low-level language. The high-level features of C++ are polluted with low-level concerns that serve as nothing more than a distraction; this has not changed with C++11 and it does not look like it will change with C++14.
So really, the only good reason to be learning C++ in this day and age is if you need to extend or maintain some part of the massive body of already-written C++ code. In other words, if you need to deal with legacy code.
> We do still have a need for a low-level language
C++ can be 'low-level' if that's what you're going to label C. How can you dismiss C++ as not being low-level and then later say it's 'polluted by low-level concerns'?
> There is also quite a bit of C code out there... not knowing C means being cut off from all of that.
I agree. Fortunately, you can't really effectively learn C++ without understanding its C legacy.
> The high-level features of C++ are polluted with low-level concerns that serve as nothing more than a distraction
Until you're working at a high level and need to dig deep and implement a gritty data structure or algorithm with a high-level interface. Sure, you can drop down from Java to C, for example, but then you're in the mud writing JNI bindings. Why do languages have to be constrained to 'high-level' and 'low-level' pigeon holes? Why can't there be room for a language that's good, but perhaps not elegant, slick or beautiful, across the spectrum?
Honestly, I don't want a religious war about it. I just think some of your assumptions are typical of people who have obvious had a bad experience with C++, having used it in a specific context, and therefore think "It didn't work for me, therefore it must be horrible".
On another note, C++ is at least improving and rapidly becoming better tooled, with a growing sense of developer community. C has had a few sprinkles of improvement, but has otherwise reached the end of its natural evolution.
I think C++ is the best procedural, 'high level', statically typed language out there. I also happen to think it's the best portable 'low level' language out there. What would your recommendation be to go alongside C?
I recently (about 2 years ago) started writing, on and off, a new IDE for Clean in C++ with Qt. No complaints. I somehow like it better than C# with all its drag and drop capabilites (yes Qt has that also). However, somehow I like Qts way of doing it better...Don't know what I wanted to say with all this, I just prefer C++ and would choose it for applications. Unless demanded otherwise.
What I said was that C++ has no advantage over C as a low-level language. When you are writing low-level code you usually do not appreciate implicit function calls, extra data being allocated that you did not explicitly declare, name mangling, etc. Low-level C++ code is basically C with a slightly modified set of annoyances balanced by a small set of conveniences.
"Why can't there be room for a language that's good, but perhaps not elegant, slick or beautiful, across the spectrum?"
It is not about being slick and elegant, it is about being productive. The majority of applications are high-level, and the programmers who write those applications get more done when they use high-level languages.
Sure, sometimes an application needs to do a few low-level things. For some high-level languages that means using an FFI (e.g. JNI for Java). We could do better if we wanted; CMUCL and SBCL are Lisp implementations that do a fantastic job of separating high-level and low-level constructs, so that you would never know the low-level features existed if all you wrote was high-level code. With C++, you get something very different: high-level code is tangled up with low-level constructs, issues, and reasoning.
"I just think some of your assumptions are typical of people who have obvious had a bad experience with C++, having used it in a specific context, and therefore think "It didn't work for me, therefore it must be horrible"."
Actually, I switched from C++ to Lisp after having programmed in C++ for more than a decade. This is not a decision I have any serious regrets about. With Lisp I am writing high-level code more easily, and what I am seeing is (a) better performance, (b) the ability to do more ambitious things, and (c) less time spent debugging. Sure, I have bugs in my Lisp code, but those are exclusively high-level bugs -- bugs in logic, bugs that I can fix without having to spend hours tracing pointers. In Lisp, I can report errors anywhere and not have to worry that my program will abort; in C++, sometimes errors just have to go unreported.
It is not that I had one bad experience with C++. I TA'd a data structures course that was taught in C++, and it was a nightmare that left the students with a poor understanding of basic data structures. I have spent countless hours debugging C++ code -- code I wrote, code others wrote, code written by gurus, code that is supposed to solve high-level problems, etc. My group almost missed an important deadline because of the time we had to spend getting C++ code to work. I have worked with people who refuse to even use C++ exceptions because of the all the problems they cause.
Really, I do not mean to rave about Lisp. It is a great language, but there are plenty of other great languages. I liked programming in F#, though I am not an expert in the language. I have seen people switch from C++ to Haskell without ever regretting their decision (including a number of people who said they would prototype their code in Haskell, then rewrite it in C++ when they needed better performance; the rewrites never happened).
"On another note, C++ is at least improving"
I found C++11 to be a disappointment, and C++14 is looking to be more of the same. C++11 contains lots of fixes to problems that are particular to C++, and those fixes introduce as many problems as they solve.
For example, AFAIK you cannot have a naked struct in C++. A struct is a class, and therefore can have methods, thus can have constructor and destructor.
Also, exceptions are a big part of C++ that I don't think you can remove?
If you want simple, obvious separation of data and logic, and you don't want exceptions or name mangling, then C is probably a better choice for that domain.
I like C++, but it is not C and is unlikely that one will ever replace the other in all the domains.
OTOH, if you want to write OO and you like C++, then it is not a bad choice.
I think both are being used to write new systems, so neither is legacy :-)
The "class" keyword and the "struct" keyword differ only in default member visibility. You're free to use the struct keyword. Yes, such structs can have member functions, but they change little except to act as a convenience. A "naked struct" in C++ is called a POD ("Plain Old Data") type, and there are a few rules to ensure your structure meets that definition. The standard library has a type trait to test a class/struct to see if it meets that definition (called std::is_pod).
> For example, constructors, destructors, virtual functions, namespaces.
None of these actually interfere with any use cases or domain that I can think of. Constructors and destructors are insanely valuable features, even if you use nothing else. Functions are not virtual by default and impose no overhead unless used.
> exceptions are a big part of C++ that I don't think you can remove?
You can turn exceptions off at the compiler level. -fno-exceptions in GCC and Clang. RTTI can also be disabled. Disabling both in embedded cases is perfectly reasonable.
> name mangling
extern "C" {} blocks kill name mangling and allow you to export a C API and ABI compatible function.
"I am already familiar with C, as well as Python, Go, Java and a few other scripting languages."
In terms of relevance in the real world, those languages cover pretty much all bases. The only reason I can see for learning more languages would be to learn entirely new ways to think about programming i.e. different paradigms. Functional programming is fine as far as that goes, but constraint programming is even more radically different (it is not likely to be viewed as simply a "style" of programming that can be used in C or Python), so I mentioned it.
Now only you will truly know if C++ is suitable for the tasks you do but unless you work at a university then chances are C++ will be good to great for whatever you need.