The future of (Modern) C++ (17)
-
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!
-
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!
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.
-
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.
I don't think MS is dooming Desktop apps, the Web & Cloud is. Besides, there are heavy apps that can only work properly on desktops, e. g. Photoshop, Cad, C++ IDEs :) And, you wouldn't make such apps in WinRT. Also, there are apps which are simply incompatible with UWP, e. g. Browsers & File managers. To summarize, UWP is OK as long as you don't fall into one of the above categories, but I really don't see a lot of C++ devs jumping into that boat, it definitely for dotneters. BTW, your statement about Qt not being standard C++ is kind of strange, Qt is not a C++ dialect, it's a framework. The C++ in Qt is as standard as your compiler assures
-
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!
Raspberry Pi is a full fledged Linux OS. Writing embedded code usually means writing for some device without an OS
-
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.
-
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.
-
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
-
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
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[^]
-
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.