The future of (Modern) C++ (17)
-
Following loosely the awesome job of Kenny Kerr at Microsoft [C++/WinRT | Modern C++ for the Windows Runtime](https://moderncpp.com/) and latest C++ specifications (v17 now), I am wondering if C++ is gonna make a come back? And if it's worth doing large scale (home, Win10, UWP) app in C++? Or I could just stick to C# - UWP. In fact I'd like to see C++ make a big dent in the job market once again.. C++17 looks quite slick. But I don't hold my breath. Even AI people (the upcoming IT kid) doesn't use much C++ on public API, as far as I can see...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
It definitely has [and will keep having] a place in high performance server-side applications. For desktop high-performance most glitzy games are still being written in C++. For less demanding stuff it is more a matter of taste, some companies like C++ others do not. E.g. Spotify R&D were 5 years ago discussing to leave C++ but I think they are still there. I think the long term desktop/phone future of C++ will be decided by the development of standardized libraries for GUI etc. Threading and networking are already nicely standardized with no OS-specific quirks.
... such stuff as dreams are made on
-
Following loosely the awesome job of Kenny Kerr at Microsoft [C++/WinRT | Modern C++ for the Windows Runtime](https://moderncpp.com/) and latest C++ specifications (v17 now), I am wondering if C++ is gonna make a come back? And if it's worth doing large scale (home, Win10, UWP) app in C++? Or I could just stick to C# - UWP. In fact I'd like to see C++ make a big dent in the job market once again.. C++17 looks quite slick. But I don't hold my breath. Even AI people (the upcoming IT kid) doesn't use much C++ on public API, as far as I can see...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
After years of working with C#, I am loathe to go back to a language where I have to work with OS native types that begin with the letter
H*shiver* ;)Latest Article - Contextual Data Explorer Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
After years of working with C#, I am loathe to go back to a language where I have to work with OS native types that begin with the letter
H*shiver* ;)Latest Article - Contextual Data Explorer Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
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](https://moderncpp.com/) (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!
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Following loosely the awesome job of Kenny Kerr at Microsoft [C++/WinRT | Modern C++ for the Windows Runtime](https://moderncpp.com/) and latest C++ specifications (v17 now), I am wondering if C++ is gonna make a come back? And if it's worth doing large scale (home, Win10, UWP) app in C++? Or I could just stick to C# - UWP. In fact I'd like to see C++ make a big dent in the job market once again.. C++17 looks quite slick. But I don't hold my breath. Even AI people (the upcoming IT kid) doesn't use much C++ on public API, as far as I can see...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
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.
Nish Nishant Consultant Software Architect Ganymede Software Solutions LLC www.ganymedesoftwaresolutions.com
-
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.
Nish Nishant Consultant Software Architect Ganymede Software Solutions LLC www.ganymedesoftwaresolutions.com
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.
-
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](https://moderncpp.com/) (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!
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
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...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
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.
Nish Nishant Consultant Software Architect Ganymede Software Solutions LLC www.ganymedesoftwaresolutions.com
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.
-
Following loosely the awesome job of Kenny Kerr at Microsoft [C++/WinRT | Modern C++ for the Windows Runtime](https://moderncpp.com/) and latest C++ specifications (v17 now), I am wondering if C++ is gonna make a come back? And if it's worth doing large scale (home, Win10, UWP) app in C++? Or I could just stick to C# - UWP. In fact I'd like to see C++ make a big dent in the job market once again.. C++17 looks quite slick. But I don't hold my breath. Even AI people (the upcoming IT kid) doesn't use much C++ on public API, as far as I can see...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
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
-
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.
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
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.
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
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.
-
Following loosely the awesome job of Kenny Kerr at Microsoft [C++/WinRT | Modern C++ for the Windows Runtime](https://moderncpp.com/) and latest C++ specifications (v17 now), I am wondering if C++ is gonna make a come back? And if it's worth doing large scale (home, Win10, UWP) app in C++? Or I could just stick to C# - UWP. In fact I'd like to see C++ make a big dent in the job market once again.. C++17 looks quite slick. But I don't hold my breath. Even AI people (the upcoming IT kid) doesn't use much C++ on public API, as far as I can see...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
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 hist
-
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 hist
I got you man! :) In fact I am not *in love of C++* nor want *deep control* but 1. I want C++ to be as easy as C# + Xaml stack 2. 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. 3. 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.
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
I got you man! :) In fact I am not *in love of C++* nor want *deep control* but 1. I want C++ to be as easy as C# + Xaml stack 2. 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. 3. 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.
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
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".
-
I got you man! :) In fact I am not *in love of C++* nor want *deep control* but 1. I want C++ to be as easy as C# + Xaml stack 2. 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. 3. 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.
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
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.
-
Following loosely the awesome job of Kenny Kerr at Microsoft [C++/WinRT | Modern C++ for the Windows Runtime](https://moderncpp.com/) and latest C++ specifications (v17 now), I am wondering if C++ is gonna make a come back? And if it's worth doing large scale (home, Win10, UWP) app in C++? Or I could just stick to C# - UWP. In fact I'd like to see C++ make a big dent in the job market once again.. C++17 looks quite slick. But I don't hold my breath. Even AI people (the upcoming IT kid) doesn't use much C++ on public API, as far as I can see...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
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#
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
C++ (or C) has been and will continue to be pretty much the only game in town for embedded.
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.
-
Following loosely the awesome job of Kenny Kerr at Microsoft [C++/WinRT | Modern C++ for the Windows Runtime](https://moderncpp.com/) and latest C++ specifications (v17 now), I am wondering if C++ is gonna make a come back? And if it's worth doing large scale (home, Win10, UWP) app in C++? Or I could just stick to C# - UWP. In fact I'd like to see C++ make a big dent in the job market once again.. C++17 looks quite slick. But I don't hold my breath. Even AI people (the upcoming IT kid) doesn't use much C++ on public API, as far as I can see...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Writing RaspberyPie app right now at work, with C#
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
