There was one brief stretch in history around 1994-1998 where C++ was the best choice for application level programming. And even then only a very narrow type of app programming.
Before that brief timeframe and since then it has been a poor choice for every single type of programming. There are better choices in all cases. It has no niche anymore where it is the best fit, not anywhere.
C++14 (the latest standard) is a far better language than C++ in the '90s, and it really does beat C when it comes to abstraction capabilities, type safety, and standard library functionality. C++11 also defined a standardized memory model which is extremely useful for writing multithreaded code.
Yes, C++ is not perfect -- the C++ standard library lacks a lot of functionality found in the libraries of other languages; there is a lot of complexity in the language that one must master to really "know" C++; the language itself has dark corners and disappointments; and so on. No language is perfect, and every language permits bad code.
I've been working with C++ full-time for the past three years. I didn't know much about the language before then (I was a "C 43var!" guy), but had heard all the horror stories about it. Now, I'm convinced that it's probably the best general purpose programming language available to date. It combines the full power of the machine with very expressive abstraction capabilities. Having seen what can be done with C++, I decided to study harder and try to master it.
I think this last point is ultimately what puts people off, and leads to a lot of FUD about C++ -- it takes hard work to master the language and the tools to work with it. Nobody really wants to do that, not when there are seemingly viable, and easier, alternatives. Instead, people are more willing to invest huge amounts of effort and money to try to scale up those alternatives if it means they can avoid the complexity of a language like C++. That's fine, I guess, we all have to make the appropriate engineering trade-offs, it's just unfortunate that many people fall into extremism about it in order to justify their attempt to simplify the reality of computing (which is actually considerably complex).
For memory-sensitive applications where time-amortization hurts (and this turns out to be pretty much every application that anyone wants to run on their local computer), C++ is still king and is still the best choice for the job. Everyone hates C++, and yet every desktop application in widespread use is built with it. I wonder why? Is it really just inertia?
Java, C# - programmers are stuck with a runtime that literally consumes 10x ram as equivalent C++ software. Do you like switching applications on your Android phone and having every other process pushed out of memory? I didn't think so. And while both environments are now offering ahead-of-time compilation, the CLR/JVM runtimes are still much larger than what C++ consumes and you give up the only chance of matching C++'s runtime CPU performance (harvesting runtime profiling to inform the JIT).
Golang - a huge step in the right direction, this will probably end C++ use on servers and hosts eventually. It still can't match C++'s runtime performance, but who cares in a host environment. Still, garbage collection makes it unsuitable for local applications where users notice micro-pauses due to garbage collection. Nothing is worse than going into alpha with 10 P0 bugs complaining about 'micro-pauses' and finding out it's because of something you can't change in the runtime.
D - truly a better C++ than C++. But no one uses it.
Rust - our best hope so far, but the compiler and standard library aren't there yet. You still can't program a web server, for example, without manually handling unsafe objects. Even then its going to be years before there are libraries available that are of similar quality to things like Qt. How do make a GUI application in Rust in 2015?
C - I hope you like (void*) and all of the fun runtime bugs that introduces.
But seriously - "There are better choices in all cases"? Like what?
Runtimes like Java that want to install the runtime as a separate package on the system which must be separately approved and separately maintained. This also results in loads of different versions of the same runtime installed on the same machine.
As an alternative, the app author may sometimes bundle the runtime. Result: package bloat.
As another alternative, the app author may statically link the runtime. Result: binary bloat.
So your choice is between included bloat and secondary install bloat, not to mention version management nightmares and conflicts and other horrors.
Java's deployment issues are what killed it as a platform for shipping desktop apps. I tried to ship a desktop app with Java once, and never will again. C# is a bit better as it's generally installed on all Windows machines, but is MS only so is not portable.
C++ = portable, not horribly bloated, deployable, update-able, and mature.
There aren't any alternatives. This is not really a technical problem... it's just that nobody has gotten their act together to ship something that addresses these concerns. A lot of programmers don't seem to understand installability and ship things that demand follow-on package dependencies and other bloat. General rule: every installation step or sub-package exponentially increases the difficulty of deployment and maintenance.
Another problem is that these languages try to do too much. They try to be languages and runtimes, which in practice means they're OSes-within-the-OS. That means bloat is pretty unavoidable. A JVM is functionally not far from a VM running in a hypervisor, so you might as well just ship apps with Vagrant or something.
First off, that is incorrect. You underestimate the number of VB, C#, and other apps, not to mention OSX based apps. Most business apps are either in Java on the backend or if they aren't web based they are in proprietary languages and frameworks that likely use a mix of C and C++ at the core. They are mostly shit nowadays though which is why everyone is re-writing them in the Cloud. They're unmaintainable.
But yes there are a lot of high visibility popular desktop apps in C++ and yes, it is just inertia. When were all of those desktop apps you're thinking of first built (or came of age)? The early 90s! Microsoft Office, the Adobe suite, Visio (bought out by Microsoft), desktop databases, etc.
That was the age of the desktop and briefly, C++ was the best choice. I'll grant you a few very small niches still exist and they are in the desktop domain e.g. web browsers and very complex image editors. But how many people are writing browsers? And simpler image editors are better off being mostly in Objective-C or C# (minus some core libraries which are best off in C).
I'll grant you a few very small niches still exist and they are in the desktop domain
Show me a popular desktop app written in something other than C++. Even when developers have tried to write a desktop app in something other than C++ (like Evernote on Windows) it was deemed a failure and was re-implemented in C++.
And you still haven't presented a compelling argument for choosing C over C++. C++ IS C, but with extra stuff that makes it better, like generics, custom types, alternatives to C's nuclear-powered casting, strings that don't blow up in your face, etc, etc. Why should a core library only be written in C?
C++ is only used for the COM interfaces used to talk to the measurement devices.
Evernote's case if I remember correctly was mainly caused by them using .NET 3.5 without much knowledge of the eco-system.
WPF in .NET 4.5 is not the same as the Evernote guys used.
I do like C++, but I rather use the safety and tooling of other languages.
Only C++ Builder and now XAML with C++/CX can offer similar capabilities.
EDIT: improved the content.
Qt seems to be going JavaScript gluing C++ components, given that many of the new features are QML only.
Eclipse is the only one that comes to mind.
I'm not sure the state of consumer Windows apps but almost all desktop business apps are in C# or VB. Unless of course they are accessing legacy C++ stuff.
I can give you a few more: Chrome (not entirely new, but still the newest major browser around), Sublime Text (compare its performance with Atom to realize the strengths of C++), GoldenDict, Scan Tailor.
Actually, I've tried thinking of new Desktop apps which came out in the last 5 years and there weren't many. Developing new desktop apps is just not as popular as it used to be 10 years ago. It has a lot to do with the rising prominence of web and mobile apps, but this also has something to do with C++, when I think about it.
Writing a cross-platform web app with acceptable performance is easier than writing a desktop app with the same properties, since you'd almost certainly need to use C++ to get an app with the same properties on the desktop.
With web apps you essentially get cross-platform for free (at least since the days of jQuery and IE shims) and the performance is not stellar, but at least it's not worse than all the other web apps, so it matches your users expectations.
On the desktop, you usually get three routes: 1. C++ app with a cross platform GUI toolkit (probably Qt, since GTK user experience is usually horrible on anything other than *NIX) or an abstraction layer like wxWidgets. 2. Cross-platform Java or Mono/.NET app with cross platform GUI toolkit. There are occasional exceptions, but these apps generally tend to be bloated or hard to install, and never match the snappiness of native apps. 3. Write a separate native front-end for each platform, using its own native GUI toolkit. This usually means C with @WinForms/WPF for Windows and Objective-C with Cocoa for Mac. If you have a shared backend, you would usually still be forced to use C or C++ to make it usable with both runtimes.
These are not "legacy" apps. They are huge cutting-edge professional suites that drive massive chunks of the economy and contain some of the most complex and challenging computer code ever written. We're talking about stuff like Monte Carlo analysis and genetic algorithm generation of physical machines, simulation of massive electronic circuits, etc... some of these things are the closest thing software engineering has to modern wonders of the world.
Go try re-implementing SolidWorks in JavaScript as a client/server app or for Android or iOS and then tell me desktop is dead. Then there's the whole issue of security, privacy, and data ownership. Cloud demands a lot of trust in the provider, and mobile treats user data with something near contempt (apps "own" their files, etc.). There is absolutely no way I am writing a novel or a Ph.D thesis in the cloud or on a mobile device. I'm doing it on a machine I control with a backup system I control where an app being pulled from an app store or a cloud provider experiencing a hack/failure won't obliterate my two years of work.
Granted that such things can be written now in languages other than C++, and sometimes can even be shipped in those languages without torturing the user with secondary runtime installs and other insults. But C++ still really rules here. You write it, you build it, and you ship it. Bloat is fairly minimal. Even if you use Qt the bloat is still a lot less than Jabba.
Good examples though. If you were building them from scratch, I would still question the choice of C++ for these as opposed to C#, Objective-C native UI layers combined with a C core.
This is a bizarre claim. C++ has its problems, but the fact that it allows zero-overhead abstractions over common low-level boilerplate is a seriously non-trivial advantage over C in most areas where C is otherwise a good fit. What compelling advantage does C retain over C++? Faster compiles and being easier to learn are nice and all, but hardly slam-dunks.