3 ms·

Show me non-legacy desktop apps that were written in the past few years that are in C++. I believe the majority of ones I use on the Mac were written in Objecti

Show me non-legacy desktop apps that were written in the past few years that are in C++. I believe the majority of ones I use on the Mac were written in Objective-C. If they aren't using specialized legacy libraries (e.g. image processing) I bet I don't have a single one that is in C++ other than image editing and browsing. 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.

unscaled 12y ago
The post you're replying to just did: Evernote 4 for Windows was rewritten from scratch in C++ (with WTL). It was C#/WPF before. 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.

unscaled 12y ago

The post you're replying to just did: Evernote 4 for Windows was rewritten from scratch in C++ (with WTL). It was C#/WPF before. 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.