|
That's the thing, C++ 17 looks almost like C#, lambda expression, async code, auto keyword (aka var in C#), etc...
And when you looks at some UWP App with C++/WinRT | Modern C++ for the Windows Runtime (to be included in next Windows SDK in .. April?) it really read and write as simple as C#.... (I just discovered today it's not in the current SDK  gotta keep an eye on SDK 17025)
I think I will start playing with it in earnest with then.. can't wait for that release!
|
|
|
|
|
Super Lloyd wrote: (I just discovered today it's not in the current SDK gotta keep an eye on SDK 17025)
It's available beginning today in the Windows 10 SDK Preview Build 17120[^]
Best Wishes,
-David Delaune
|
|
|
|
|
Ha, it's on the insider preview, will wait....
Not really keen on installing virtual machines at home...
+ my internet is just mere ADSL.. not up to speed to download zillion of gigabytes...
|
|
|
|
|
Kenny's work is wonderful for sure, but I am afraid it's too little too late. I don't see enough of a push from Microsoft presenting C++ as a cloud development language. I am not even sure if it's even possible without jumping through hoops to deploy C++ code into Azure. Azure functions support multiple languages including C#, JS, Python and even PHP (but not C++). And no one's going to write a web-app UI in C++. Even for UWP, most apps are thin UI clients that consume an API - and it's far easier to develop/debug those with C#. High performance backend code is the only area where I can see someone consciously wanting to use C++. Even there managed languages are getting so much better, and when the bottleneck is the database/network, it evens out the minimal differences in performance.
|
|
|
|
|
I agree. Managed languages really do cut the cost of software development, and I see that as a really strong motivator for companies to stick with them.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
There are at least 2 serious frameworks for Web using C++: Wt and cppCMS.
As for WinRT, the whole idea of writing sandboxed Windows applications is not very appealing to most C++ developers, since it has many limitations that feel uncomfortable, after all C++ is all about control.
|
|
|
|
|
As a C++ developer, WinRT is definitely not something I would want to use, because of its limitations, to me nothing sounds more boring than "sandboxed windows applications".
However, I am a bit biased here, since I am not a big fan of MS dev environment. Anyway, I would prefer MFC over WinRT any time (and Qt over MFC, for that matter).
In any case, to answer the C++17 part, the areas where C++ is more powerful than ever is:
1. embedded,
2. car infotaiment systems,
3. Heavy apps like Adobe Photoshop or AutoCAD
4. AAA games and game engines
5. Cross-platform apps (Java and C# really sucks at crossplatform desktop apps)
6. Libraries
|
|
|
|
|
our answer got me thinking...
In fact I was looking for a C++ API that I found comfortable enough to use everyday for writing desktop app. Kenny Kerr seems to finally be it!
Why, you ask, well I want to mix and match with DirectX, so C++ is mandatory... But I want the same level of comfort I have with C# + Xaml stack, or acceptably close.
So I guess I should just give a go to ModernC++ (Kenny's work) when it is available.
As for other system... is there something that compare to WPF / UWP? ...
I am not talking about the sandboxing here, I am talking how elegant it is to write GUI using XAML and data binding.
|
|
|
|
|
Well, I don't find UWP elegant or appealing, as you can understand.
As for WPF analogues for other systems, I'd say only Qt compares with it but it's not really analogue, you won't find any analogues for sure.
Also, Mac might have something similar, but I'm not a Mac user.
|
|
|
|
|
|
After many years of C/C++ programming, I took over a couple C# projects about six years ago, and was rather sceptical about the whole thing: Managed code, automatic garbage collection, ... But the code base was established long ago; language choice was not an option.
Then, after 3-4 years of C# coding I picked up one of my hobby projects ideas, returning to the efficient, full control, knowing-what's-really-going-on C++. ... I waded through a sump in a dense jungle of setup and initialization and management code that had no relatioship whatsoever to the problem I wanted to solve, but things like space management, interface to the OS, nitty-gritty I/O details... Trivial work that I really wish I could pay the neighbour's kid to do. But then I would loose control again.
And, I decided: I trust the C# compiler more than the neighbour's kid. It will do a professional job. And looking at e.g. the heap management methods, they are far more intelligent than my own C++ versions ever were. My C# code spends a far lower percentage of the code on non-problem-related setup and management: Execution dives right into the actual, application level, user visible task that the system is meant to solve. You don't need loads of code just to pet the programming language on its head.
I have done a few timings to see how "bad" performance C# has, compared to C++. Of course it varies with the kind of operations you do, and I haven't yet seen C# beating C++ (I never expected to) - but usually, running C++ code on the previous CPU generation, C# on the latest, they come out as roughly equal. My productivity being much higher, and my error rate much lower, when using C#, I have no desire to go back to C++.
When I tried to return to C++, I was still on Visual Studio 2010. I had been impressed with the programmer support it provided for C#, both in catching typos etc long before a build was attempted, and in helping me find the right functions etc. I expected the C++ support to be on the same level (previously, I had not been using a modern IDE when coding C++), but was very disappointed. I believe much of is the "flexibility" (or "You asked for it, you got it") of C++: The compiler (/VC syntax analyzer) simply cannot smack your fingers when you do something silly - it is silly, but legal C++ nevertheless... (prime example: Pointer arithmetic). Now I am on VC 2017, maybe C++ programmer support is now at the same level as for C#. I haven't tried C++ with VC 2017: Assembler coding (I've done my share of that!) belongs to history, so does C++. For me. (I would even start assembly coding again if I were paid a million, and again: so I would with C++.)
In my "computer humour" scrapbook, there is a discussion from 1998-99 (on NetNews/Usenet...) with this guy insisting that high level languages are a fad: They will never be able to compete with properly written assembly code. Well, it can. GC can compete with most hand-written heap management code. On-the-fly compilation of the intermediate language can be fine-tuned for the specific CPU in use. It will not go away. Even in the long run, a few people will need to know assembler language, a few will have to know Fortran, a few will have to know how to handle pointer arithmetic. But it won't be mainstream again.
|
|
|
|
|
I got you man! 
In fact I am not in love of C++ nor want deep control but
- I want C++ to be as easy as C# + Xaml stack
- I want to use DirectX seamlessly
and speaking of which Kenny Kerr work in upcoming SDK 17025 seems to be it. Really impressed. Upcoming C++ 17 standard helps too.
- I would like C++ to be as easy as C# to integrate with other .NET work, with off chance I hit a scenario offers critically more performance.
And, could you believe it, I hit that scenario today at work. In an UWP app we were accessing some low level hardware but some operation was 100x times faster in C++. Turns out it is because, I believe, any high level device operation requires reading and writing lots of small array. Having a huge cross ABI boundary cost.
Luckily writing a C++ UWP component available usable by my C# project proved easy. Although I couldn't get to reference a C# interface in the C++ component, ending making it standalone.
Finally thanks for your feedback. It was interesting and relevant.
|
|
|
|
|
Quote: Luckily writing a C++ UWP component available usable by my C# project proved easy.
I think this is the best approach, for now. Need a high-performance/control module? Make a C++ library and just integrate the project. BAM! Best of both worlds, with some "overhead".
|
|
|
|
|
Most of my C# coding has been GUI and file system related. Timing comparisons are relevant only on selected parts with no user interaction. For file system operations, disc waiting time may easily be ten times the processing time - and that waiting is roughly programming language independent, unless the language libraries use different buffering strategies (and then you are comparing buffering strategies, not languages).
So, for a long time I had overlooked the "Optimize code" chekcbutton in the VC project properties: For the GUI/disk related projects it really didn't matter. When I checked it, CPU bound code became approximately 4 times as fast(!) (but cannot be properly debugged). Now I would certainly like to rewrite some of that CPU bound code in C++ to see if there is anything to gain. I guess that it will be very little!
(By the way: There is no noticable speed difference between x64 code produced directly by the C# compiler, compared to CIL generated by the compiler with final code generated by dotNet to x64 on the first run. I didn't expect there to be - but lots of people believe that the just-in-time code generating imposes a heavy perfomance penalty.)
As you say: C++ (or just plain C) has its place as a CPU independent (high level) assembly language, e.g. for interfacing to hardware. In the old days, libraries were written in assembly, nowadays in C/C++. They make the interface available to e.g. C#, but you won't get completely away from assembly/C to create the interface library.
|
|
|
|
|
Member 7989122 wrote: there is a discussion from 1998-99 (on NetNews/Usenet...) with this guy insisting that high level languages are a fad: They will never be able to compete with properly written assembly code. Well, it can. GC can compete with most hand-written heap management code.
Rather certain that I was looking at a automated GC for C++ in the 90s. It was an add in library of course. And one needed to adapt certain ways of working.
But of course in C# and Java, both with automated GC, one must adopt to the reality that computers have many resources of which memory is just one. So one must adapt to certain ways of working - one must always explicitly manage everything except memory. With C++ however one can manage other resources via the scope (dtors) and do so with complete control.
Member 7989122 wrote: But it won't be mainstream again.
Certainly for my definition of "mainstream" it is in fact exactly that. And it hasn't changed much in the last 20 years.
TIOBE Index | TIOBE - The Software Quality Company[^]
|
|
|
|
|
jschell wrote: one must always explicitly manage everything except memory.
Most certainly not.
When we were students, some OSes/file systems (notably: an IBM mainframe we ran a big project on) required you to manage disk space explicitly: You had to reserve the amount the file would require, as one contiguous chunk on the physical disk. (Certainly, we had been working on other systems with automatic disk space management for more than three years, and refused to believe it when this IBM guy gave us a lesson in how to create a file, but it was true!)
I am too young to myself have experience with setting up a job mix where one job would use the CPU while another job did I/O, but a couple of my older textbook discusses this. However, we have had automated CPU management for several decennies.
Even communication has gone from static swithed lines to statistical multiplexing, where every user is automatically allocated capacity according to needs.
So memory management is certainly not the only area for automatic management.
|
|
|
|
|
C++ (or C) has been and will continue to be pretty much the only game in town for embedded.
|
|
|
|
|
Writing RaspberyPie app right now at work, with C#
|
|
|
|
|
The PI is not an embedded device compared to the processors I work with. I usually have 256K or less RAM to work with, some as small as 32K. C# is not going to be running on these devices.
|
|
|
|
|
Raspberry Pi is a full fledged Linux OS.
Writing embedded code usually means writing for some device without an OS
|
|
|
|
|
There are scaled-down OSes for embedded use as well. The Wikipedia "Embedded operating systems" category page has quite a few entries. Certainly, a lot of the entries are not OSes, some are propritary OSes, some may not qualify as "embedded" and some may not qualify as OSes.
The one I have been in touch with is Zephyr, which certainly qualifies as an OS, and certainly as embedded (it can well run on, say, IoT chips with less than 256k), it is open-source and implemented on a number of typical embedded-class CPUs.
|
|
|
|
|
Totally agree.
I was just pointing out the general case.
|
|
|
|
|
Yep, every embedded processor I've developed for in the last 20 years has had a C/C++ compiler available for it (and not much else). Unfortunately, they've also been years behind the curve. The current TI C++ compiler (I do a fair amount of DSP work) is only at the C++(03) level.
|
|
|
|
|
3 of the last 4 jobs I have had all involve C++. Two involved both C++ and C#. My current position is as a C++ software developer. I always hear it is dying but I don't see that really happening. We are just not as flashy as the Web devs. 
|
|
|
|
|
A niche where C++ could fit, I think, is in the field of webapis. Picture a RESTful service that does the heavy processing efficiently as only a good piece of C++ code can do. Front ends (for web or mobile) can be done using C# or Java or Swift. When you install these webapis to the cloud, it would mean (at least theoretically) less memory and probably less CPU usage (if the C++ code is optimized), which would translate in less resources and a less expensive Azure bill.
But I haven't seen a framework for C++ webapis apart from half-baked projects that stopped active development long ago. So unless you want to go creating ISAPI extensions or good old CGIs, I don't see it happening anytime soon.
As for desktop development, Microsoft won't upgrade MFC nor will opensource it, and neither Qt nor C++/CX are actually standard C++ (and WinRT seems too much complicated to invest in a sandboxed environment) so I don't think C++ will come back to desktop anytime soon. Plus, Microsoft doesn't seem interested in desktop development aside from their UWP, essentially dooming (IMO) desktop apps.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
