And I?ll give my usual refrain in reply ? why would you want it
I am old and full of vitriol, but I have worked on a vast array or projects across different disciplines over the years. Earlier today I had to explain to a new hire that yes, x86 (although numerically superior) is actually older than x64 and I have been conscripted to fix and ASP.NET API. Last month I was working on a Cobol extract in EBCIDIC from AS 400. I?m sure I forget half of the stuff, but in addition to KM programming in Windows and Linux, I?ve worked with at least two dozen languages over the years solving all sorts of problems.
One starts to see patterns after a time.
Assuming that one has a goal oriented view of the world, then which is the better goal to have:
- My life as a developer is easier; or
- The quality of the work produced by my efforts is higher
One might argue that #2 is achieved by default by satisfying #1 (as Peter has done in his other thread RE MSFT engagement) , but which one is the higher goal? The goal of sloth or of achievement?
Assuming then that we want to achieve things, we are looking for tools that will help us achieve.
A ?high level? language like C helps us to achieve versus writing in assembly language because there is an obvious transmutation ? we change the whole paradigm of how we work from registers and addresses into variables and structures. Yes there are some kinds of algorithms which cannot be as effectively written in C as in ASM, but they are few.
An even higher level language like C# helps us achieve versus writing in C (or assembly language) because there another obvious transmutation ? again we change the whole paradigm of how we work. In this case it is all about memory management in the error cases
An event higher level language like TSQL helps us achieve by allowing us to express the DDL or DML operations of interest without having to specify how those operations will be carried our (lots of this has come to C# to via LINQ)
And then we go into the goofy land of Excel MACRO?s, power shell scripts, and the plethora of web service techniques. Not that they are bad per se, just that they are the top of the pyramid.
On this pyramid there are many ugly duckling steps and C++ is the most notable of them all. It is a neither nor language and has all of the faults of the step below without all of the benefits of the step above. There are many others with the same problem and it is not a knock on C++ just because it is more famous.
In point of fact I am presently engaged in a support incident with MSFT that stems from their use of C++ in an ODBC driver. We call the C API on the upper edge (as per the ODBC standard) and they call the C win32 API on the lower edge, but in the middle, their code does not handle all possible errors correctly and C++ exceptions ?leak? out of the top edge back into my code. The support lead has reviewed the source code and confirmed a bug in the MSFT code, but they presently don?t plan to fix it because the cost of testing the change would be too high unless I can demonstrate this is in fact not the ?one in a million? that they think it is by producing a pattern of crash dumps from our real world application failing.
At this point, I might need my own pontification, but if anyone is still reading, a further important consideration not often discussed, is the quality of run time library support. The CRT is a very poor library overall versus the stock code available for C++. That does not make C++ as a language better, but it can reduce the work that someone needs to do to write a particular program. Similarly, C# has as extensive runtime library that finally supports (with LINQ and the concurrent generics) a proper decent set of data structures and algorithms. Exactly the same kind of support can (and has at least by me) be written in C. As an aside, looking at the .NET reference source is an eye opening activity ? many of the implementations are shockingly bad
I am old and my vitriol is ebbing with this much venting. Hopefully it will be of some help to some one to read this
Sent from Mailhttps: for Windows 10
________________________________
From: xxxxx@lists.osr.com on behalf of xxxxx@osr.com
Sent: Friday, July 6, 2018 5:06:41 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Modern C++ Features in Kernel Mode Drivers
Hi All…
This is my annual lamentation, or pursuit of my personal holy grail if you will, about the chances of our seeing anything like modern C++ in the Kernel during my lifetime.
Back last year, we had SOME glimmer of sunshine from Mr. Tippett:
http:
And since then, well… the Visual Studio C++ compiler has gotten better (it’s C++ 17 compliant now) and C++ 20 has promised us even more cool shit like contracts (see Herb Sutter’s recent blog post on this topic).
But I still don’t see much hope for us on the kernel-mode front.
Why CAN’T we use std::unique_ptr, for example? Will static initializers ever get called? Will my dreams of using std::vector in my driver ever be fulfilled?
Anybody have any new insight/experience/whining to share?
Oh… It’s hardly thrilling, but… you can use C++ 17 attribute specifiers. So… you can now officially thrill yourself and put [[fallthrough]] in your case statements.
Sigh…
Peter
OSR
@OSRDrivers
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></http:></https:>
). And also the book says — It is difficult to write exception safe C++ code, and that was then, time is now. I don’t know if situation changed on this exception front.