C++ standards proposal for kernel STL subset

NTDEV
1

I’ve been working on a paper for the C++ standard. I’ve done an initial presentation at the Nov 2017 meeting in Albuquerque, but I figured I can show off an early revision of my next draft here. Link to the draft:

https://github.com/ben-craig/freestanding_proposal/blob/master/freestanding.pdf

The general idea of the paper is to specify a subset of the standard library that is useful for kernel and embedded programming. I try to add everything in that doesn’t require OS support, and doesn’t require space overhead. This particular paper is only adding things to the pre-existing “freestanding” implementation, but later papers will try to remove things as well. I’d love to hear any comments that people have so that I can incorporate the feedback into the paper before the March 2018 meeting in Jacksonville.

2

A big problem to using most C++ class libraries is they depend on C++ exceptions, which are not really supported in kernel mode.

I’ve been writing some user mode code recently, and some of the features in modern C++ would sure be nice in kernel mode, like how having lambdas allows the creation of interesting async and parallel flow control.

I’ve written a lot of C++ kernel code in the past, but my experience has been it’s difficult to get a team to accept it, for some valid and not so valid reasons. C++ is fully supported on Windows, but to get C++ kernel code accepted into the Linux mainline would take an act of God, which means if you want portability across platforms C++ is a problem.

I’ll read your paper in detail and give you specific feedback long before March. Thanks for trying to get kernel and embedded development to use modern tools. Embedded already has significantly adopted C++, like MBed and many vendor specific class libraries.

Jan

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of ben.craig@ni.com
Sent: Monday, January 15, 2018 6:29 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] C++ standards proposal for kernel STL subset

I’ve been working on a paper for the C++ standard. I’ve done an initial presentation at the Nov 2017 meeting in Albuquerque, but I figured I can show off an early revision of my next draft here. Link to the draft:

https://github.com/ben-craig/freestanding_proposal/blob/master/freestanding.pdf

The general idea of the paper is to specify a subset of the standard library that is useful for kernel and embedded programming. I try to add everything in that doesn’t require OS support, and doesn’t require space overhead. This particular paper is only adding things to the pre-existing “freestanding” implementation, but later papers will try to remove things as well. I’d love to hear any comments that people have so that I can incorporate the feedback into the paper before the March 2018 meeting in Jacksonville.

—
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:>

3

xxxxx@pmatrix.com wrote:

A big problem to using most C++ class libraries is they depend on C++
exceptions, which are not really supported in kernel mode.

 

I’ve been writing some user mode code recently, and some of the
features in modern C++ would sure be nice in kernel mode, like how
having lambdas allows the creation of interesting async and parallel
flow control.

Async and parallel flow control are perhaps the worst case, because the
threading options in the kernel are so different from the threading
options in user mode.  Just having containers, iterators, and algorithms
would be a HUGE win.

…C++ is fully supported on Windows, but to get C++ kernel code
accepted into the Linux mainline would take an act of God, which means
if you want portability across platforms C++ is a problem.

And God, in this case, is literally one person.  Linus Torvalds is
religiously and irrationally against C++.  It will never run in the
kernel while he is alive.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

4

Unfortunately, my proposal doesn’t add any containers. It does add iterators and algorithms though.

Both embedded and kernel environments don’t like using the default semantics of operator new. That disqualifies almost all of the existing containers. Std::array and std::string_view (not a container, but close) would be fine, except that some of their methods throw as well. There was concern from the Library Evolution Working Group (LEWG) about adding only part of a class to the subset. So this paper doesn’t add them to the kernel-safe subset, but a later proposal may add them, with the handful of throwing methods removed.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-645100-
xxxxx@lists.osr.com] On Behalf Of xxxxx@probo.com
Sent: Tuesday, January 16, 2018 12:35 PM
To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] C++ standards proposal for kernel STL subset
>
> xxxxx@pmatrix.com wrote:
> >
> >
> > A big problem to using most C++ class libraries is they depend on C++
> > exceptions, which are not really supported in kernel mode.
> >
> >
> >
> > I’ve been writing some user mode code recently, and some of the
> > features in modern C++ would sure be nice in kernel mode, like how
> > having lambdas allows the creation of interesting async and parallel
> > flow control.
> >
>
> Async and parallel flow control are perhaps the worst case, because the
> threading options in the kernel are so different from the threading options in
> user mode.? Just having containers, iterators, and algorithms would be a
> HUGE win.
>
>
> > …C++ is fully supported on Windows, but to get C++ kernel code
> > accepted into the Linux mainline would take an act of God, which means
> > if you want portability across platforms C++ is a problem.
> >
>
> And God, in this case, is literally one person.? Linus Torvalds is religiously and
> irrationally against C++.? It will never run in the kernel while he is alive.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: https:> 3A www.osronline.com_showlists.cfm-3Flist-3Dntdev&d=DwID-
> g&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-
> UCZRX0Vl1g&m=XHQsxwnxoB9PNAD2Hd73Pd6THb-
> BXrtuWsIPypyDLbE&s=Gfcj5tiCKIA3Kxsx1uZLDTyv23y6KtEeBgNgzIzJa9Q&e=>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at https:> 3A www.osr.com_seminars&d=DwID-
> g&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-
> UCZRX0Vl1g&m=XHQsxwnxoB9PNAD2Hd73Pd6THb-
> BXrtuWsIPypyDLbE&s=4o1-
> 2YDnM1le8cXUhCbaaEf8ZHPZaHpbnQjn0f1vXaM&e=>
>
> To unsubscribe, visit the List Server section of OSR Online at
> https:> 3A__www.osronline.com_page.cfm-3Fname-3DListServer&d=DwID-
> g&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-
> UCZRX0Vl1g&m=XHQsxwnxoB9PNAD2Hd73Pd6THb-
> BXrtuWsIPypyDLbE&s=6B4n7Q8NOYgZxBp_HusVphEOeWrtE7SsOI8g2wjg-
> wE&e=></https:></https:></https:>

5

Again!

We are now in 2018 and you would think that by now, instead of trying to fix C++ for the kernel, academia and standards bodies would get behind C# or another of the G3 languages that were designed to avoid fundamental limitations in C++.

C++ has its advocates (I am not one of them) and it is certainly useful in certain circumstances over either of my preferred languages (C & C#), but the weight of history and the considered judgement of many engineers working on their individual projects is against its adoption in specific areas of programming ? and with a cursory look at your paper, that seems unlikely to change.

The key problem has always been that it is very easy to write a very bad program in C++; IMHO very much easier than in C. C and C++ have the same macro and unsafe casting issues, but C++ has several additional problems. Most notably the need for exception safe design, and operator overloading are both big problems for at least code reviewers if not code authors. IMHO, correct exception based error handling in the absence of a garbage collector is much harder than return code based error handling not in the least because it is shorter

Good programmers can of course use some of the features of C++ judiciously and improve their productivity and ?feel better? about the code that they write, but it has been my frequent experience that good programmers are in very short supply; generally, I mistrust shortcuts that appear to reduce work as experience suggests that they make extra work for me

Sent from Mailhttps: for Windows 10

________________________________
From: xxxxx@lists.osr.com on behalf of xxxxx@probo.com
Sent: Tuesday, January 16, 2018 1:34:38 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] C++ standards proposal for kernel STL subset

xxxxx@pmatrix.com wrote:
>
>
> A big problem to using most C++ class libraries is they depend on C++
> exceptions, which are not really supported in kernel mode.
>
>
>
> I?ve been writing some user mode code recently, and some of the
> features in modern C++ would sure be nice in kernel mode, like how
> having lambdas allows the creation of interesting async and parallel
> flow control.
>

Async and parallel flow control are perhaps the worst case, because the
threading options in the kernel are so different from the threading
options in user mode. Just having containers, iterators, and algorithms
would be a HUGE win.

> …C++ is fully supported on Windows, but to get C++ kernel code
> accepted into the Linux mainline would take an act of God, which means
> if you want portability across platforms C++ is a problem.
>

And God, in this case, is literally one person. Linus Torvalds is
religiously and irrationally against C++. It will never run in the
kernel while he is alive.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

—
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:></https:>

6

There are two schools of thought regarding memory management:

  1. Memory management is much too important to be left to the programmer

and

  1. Memory management is much to important to be left to the compiler.

Coming from a deeply embedded and realtime background, I fall into camp #2. I can see where GC has it’s advantages. Proper programming techniques (RAII comes to mind first) mitigates those advantages a GC language has over C++. In realtime, GC is a complete and utter non-starter.

Use the proper tool for the task at hand.
Developing web pages and user forms? Use C#, Java, etc.
Developing sub-millisecond time-bounded real-time systems? Use C or C++.

I’ll end in closing: If your only tool is a hammer, all the world looks like a nail. Don’t pound your way through life.

Greg

7

> Linus Torvalds is religiously and irrationally against C++.

I think that, when it comes to hating C++, even our host can take some lessons from Mr.Torvalds.

Just to give you an idea, once he even said he would happily buy Linus a drink. IIRC,it happened on NTTALK when I provided a link to one of Linus’s “famous” quotes on the topic

(just in case if yo are interested you can read it here - http://harmful.cat-v.org/software/c++/linus)

And God, in this case, is literally one person.

Well, I can provide a quotation on this topic as well

https://en.wikiquote.org/wiki/Linus_Torvalds

On a serious note, you somehow overlook the very obvious fact that, in order to be able to use C++
in Linux kernel one wold have, first of all, to provide kernel support for C++ runtime…

Anton Bassov

8

I am so sick and tired of the same old people whenever a c++ thread comes up can’t resist jumping in and saying “you know after all, if you take a gun, point it at your foot, and pull the trigger then bad things happen”. It’s a stupid argument. It’s off topic. If you are a horrible programmer who can only think of c++ in terms of how to shoot yourself in the foot we don’t care. Please stop regurgitating the same tired lines over and over again. And it has absolutely nothing to do with this topic. Fact: people here have used c++ in the kernel for decades and enjoy productivity gains due to c++. And yes, both c and c++ can be used improperly (as if there is some surprise here?). If some dodgy c programmer passes around a structure on the stack and it blue screens in the kernel (which has happened) you don’t go barging in and hijacking every single interesting thread related to c language with ludicrous off topic arguments do you? Now let’s get on topic and move that other stuff to nttalk from now on please.

----------off topic line, start reading here----------

Ben, I have a suggestion. There is some usefulness in making a nitty gritty dissertation style pdf like you are doing. But what would really be valued in the community is if you could make a 2nd, very simple handy reference that is short and sweet list showing “this works in the kernel as is”. It can link to the existing pdf you are working on as supporting documentation. This information after all, is what people really want to know.

9

> Ben, I have a suggestion. There is some usefulness in making a nitty gritty

dissertation style pdf like you are doing. But what would really be valued in
the community is if you could make a 2nd, very simple handy reference that
is short and sweet list showing “this works in the kernel as is”. It can link to
the existing pdf you are working on as supporting documentation. This
information after all, is what people really want to know.

That’s a fair point, and at some point, I’ll need to do just that. The primary audience for this paper is the C++ standards committee, and is catered to that audience, but there is definitely value in providing a paper catered to this audience.

One issue is that the list of what works today with Visual Studio is very small (at least on the library side). You can set up your include paths to sort-of get the Visual Studio STL working, but doing that ends up breaking a lot of the inlined functions in ntstrsafe.h. It’s a bit easier to take a third party STL implementation and get it working with Visual Studio, but most of the third party STL implementations are either ancient (STLPort) or don’t work with Visual Studio. I’m hoping that the standardization of this paper will give the Visual Studio time the information needed to make a subset of their STL implementation work in the kernel.

10

(sorry I’ve been away for a while… I’ve had some family issues, but now I’m back)

It’s all so complicated.

It’s well documented that I’m not a C++ fan, and I *am* a strong proponent of C#. But, you know, times change. And I’m more of a fan of using C++ features (like the std libraries) that I am of repeatedly writing the equivalent code in C. And, given that I’m not expecting C# to wind-up in the Windows kernel anytime soon, I think the community needs to look for alternatives.

What I’m MOST interested in is how we can evolve Windows kernel-mode programming practices to be safer, more robust, and more reliable.

SOME of that can be addressed by using existing library functionality (by, again, avoiding all and sundry having to write the same old routines for every driver). But MORE than that, the major issue I see relates to proper data typing to keep variables (particularly function arguments) from being misused and abused. Think “span” and “std::vector” and similar.

Sure SAL is wonderful, but we all know it’s a PITA, and is often omitted, specified incorrectly, or raggedly enforced by the compiler and/or SA tools.

About a year ago, I had a a super-interesting conversation with Neil Macintosh on this exact topic… and he pointed me to the C++ Core Guidelines and the Microsoft GSL (see https://github.com/Microsoft/GSL).

If you ask ME, I’d like to see us be able to use as much of C++ as specified in the GSL as possible in kernel-mode.

I’d also REALLY like to see the evolution of the kernel programming interfaces to be C++ typedef’ed using GSL compliant types. Because, while I can do a lot of good by crafting the internal interfaces in my driver using safer types, until I can do the same with the various functions I call, we won’t have real safety. On this, I am not holding my breath.

Peter
OSR

(P.S. I was under the impression that it was indeed possible to get the MSFT STL working in kernel-mode, with exceptions basically causing a crash or something. Never having personally done that, I can’t swear this is correct, however).

11

Ah! I just read Mr. Penguin Pants’ arguments FOR C and AGAINST C++ in kernel-mode programming.

His arguments were from 2007 and 2004, respectively. So, more than 10 years ago. They SOUND like they were written more than 10 years ago. Ten years ago, I would have agreed with him… which is really saying something, because I didn’t think there was a SINGLE topic that Penguin Pants and I could agree on. Live and learn, huh?

Back in 2004, efficiency in kernel programming was *extremely* important. We were also still in an era when we could count on C Language kernel-mode programmers as being both disciplined and competent. We could assume they knew what they were doing. It was the waning edge of that era, but it was nonetheless still that era.

Welcome to 2018. In my experience, we can no longer assume kernel mode programmers are competent, disciplined or *really* understand what they’re doing, REGARDLESS of the language we force them to use. Whether we like it or not, there are people from the subset of C++ programmers who don’t know what a memory address is and probably don’t truly understand pointers, who WILL write drivers. They just view C as as “poor subset of C++” and carry on.

In other words, restricting the interface to C Language won’t keep the incompetent, careless, or lazy out of the kernel. It won’t stop the people who don’t understands what an operating system is from writing drivers. It won’t prevent people with no concept of how memory management works, or the basics of Windows OS architecture, from cranking kernel-mode code.

As far as I’m concerned, the above is a given.

The four things we need to do about this are:

  1. Dramatically decrease the requirement to write drivers in the first place. In case you haven’t noticed, this has been happening for a while. Thank you, WinUSB and class drivers and similar.

  2. Dramatically decrease the requirement to write kernel-mode code. Thank you UMDF 2, for as far as it goes. But, until there’s a radio button that selects whether my driver builds in UMDF or KMDF, I do not view that work as being done (or sufficient).

  3. Dramatically increase the simplicity or writing basic kernel-mode drivers. Thank you KMDF and Mini-Filter. There is still a lot of work that needs to be done here, but sadly the forward progress of WDF seems to be… ah… stalled at the moment. Which is too bad, because with the right evolution of the Framework, the change from WDF 1.x to WDF 2.x could achieve reliability gains almost on a par with the transition from WDM to WDF 1.x

There’s a corollary of this, by the way: The easier we make it to write kernel-mode drivers, the less knowledgeable individuals need to be to write them. Sadly, this often results in less than rigorous implementations. I see this every day, ESPECIALLY in the land of File System Mini-Filters. People look at the model, quickly grasp it, and think they can therefore write the Mini-Filter of their dreams. Maybe they can, but it depends on what they dream. Often: Surprise! Not so much.

  1. Make the system code, both kernel-mode and user-mode, dramatically more reliable and safer. This is what I wrote about above.

In summary, back in the day, we threw up enough barriers to entry that we could prevent all but “the worthy” from writing kernel-mode driver code. That no longer works, for a long list of reasons. We’ve got to live with this fact, and continue to address it. We have to make “shooting of feet” harder to accomplish.

Peter
OSR
@OSRDrivers

12

Thanks Peter for the link, I will use it as ref. very soon :slight_smile:


I’ve some infrastructure for instrumenting large software that I can
readily use to have minimally invasive instrumentation, not like black
box perf measures.
I need to take it down to kernel(s) ( cross-platform). Should be able
to do this w/o much headache, since the C++ fancy idioms are not
there…

Now for writing the same stuff over and over for mundane C routines,
does not quite make me excited to write C++ stl. 'cause creating small
source library is all that needed.

Even as recently as 2016, Ken Thomson also mentioned it is a overkill.
So that makes two famous peoples’ dislike. So it must be something …

IMHO, it throws me off from the “Programmers Abstraction of the machine”.

-Pro

On Wed, Jan 17, 2018 at 8:16 AM, xxxxx@osr.com wrote:
> (sorry I’ve been away for a while… I’ve had some family issues, but now I’m back)
>
> It’s all so complicated.
>
> It’s well documented that I’m not a C++ fan, and I am a strong proponent of C#. But, you know, times change. And I’m more of a fan of using C++ features (like the std libraries) that I am of repeatedly writing the equivalent code in C. And, given that I’m not expecting C# to wind-up in the Windows kernel anytime soon, I think the community needs to look for alternatives.
>
> What I’m MOST interested in is how we can evolve Windows kernel-mode programming practices to be safer, more robust, and more reliable.
>
> SOME of that can be addressed by using existing library functionality (by, again, avoiding all and sundry having to write the same old routines for every driver). But MORE than that, the major issue I see relates to proper data typing to keep variables (particularly function arguments) from being misused and abused. Think “span” and “std::vector” and similar.
>
> Sure SAL is wonderful, but we all know it’s a PITA, and is often omitted, specified incorrectly, or raggedly enforced by the compiler and/or SA tools.
>
> About a year ago, I had a a super-interesting conversation with Neil Macintosh on this exact topic… and he pointed me to the C++ Core Guidelines and the Microsoft GSL (see https://github.com/Microsoft/GSL).
>
> If you ask ME, I’d like to see us be able to use as much of C++ as specified in the GSL as possible in kernel-mode.
>
> I’d also REALLY like to see the evolution of the kernel programming interfaces to be C++ typedef’ed using GSL compliant types. Because, while I can do a lot of good by crafting the internal interfaces in my driver using safer types, until I can do the same with the various functions I call, we won’t have real safety. On this, I am not holding my breath.
>
> Peter
> OSR
>
> (P.S. I was under the impression that it was indeed possible to get the MSFT STL working in kernel-mode, with exceptions basically causing a crash or something. Never having personally done that, I can’t swear this is correct, however).
>
>
> —
> 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:>

13

This is an aside request …

Can someone please suggest me a fairly comprehensive Compiler seminar !

It should cover mostly the LLVM and MS compiler (if possible) with a
broad brush on Dragon book.

I can read/study open source, but if I could use a Jumper cable, it
would save me a push …

Thanks,
Pro

On Wed, Jan 17, 2018 at 8:50 AM, Prokash Sinha wrote:
> Thanks Peter for the link, I will use it as ref. very soon :slight_smile:
>
>
> I’ve some infrastructure for instrumenting large software that I can
> readily use to have minimally invasive instrumentation, not like black
> box perf measures.
> I need to take it down to kernel(s) ( cross-platform). Should be able
> to do this w/o much headache, since the C++ fancy idioms are not
> there…
>
>
> Now for writing the same stuff over and over for mundane C routines,
> does not quite make me excited to write C++ stl. ‘cause creating small
> source library is all that needed.
>
> Even as recently as 2016, Ken Thomson also mentioned it is a overkill.
> So that makes two famous peoples’ dislike. So it must be something …
>
> IMHO, it throws me off from the “Programmers Abstraction of the machine”.
>
> -Pro
>
>
> On Wed, Jan 17, 2018 at 8:16 AM, xxxxx@osr.com wrote:
>> (sorry I’ve been away for a while… I’ve had some family issues, but now I’m back)
>>
>> It’s all so complicated.
>>
>> It’s well documented that I’m not a C++ fan, and I am a strong proponent of C#. But, you know, times change. And I’m more of a fan of using C++ features (like the std libraries) that I am of repeatedly writing the equivalent code in C. And, given that I’m not expecting C# to wind-up in the Windows kernel anytime soon, I think the community needs to look for alternatives.
>>
>> What I’m MOST interested in is how we can evolve Windows kernel-mode programming practices to be safer, more robust, and more reliable.
>>
>> SOME of that can be addressed by using existing library functionality (by, again, avoiding all and sundry having to write the same old routines for every driver). But MORE than that, the major issue I see relates to proper data typing to keep variables (particularly function arguments) from being misused and abused. Think “span” and “std::vector” and similar.
>>
>> Sure SAL is wonderful, but we all know it’s a PITA, and is often omitted, specified incorrectly, or raggedly enforced by the compiler and/or SA tools.
>>
>> About a year ago, I had a a super-interesting conversation with Neil Macintosh on this exact topic… and he pointed me to the C++ Core Guidelines and the Microsoft GSL (see https://github.com/Microsoft/GSL).
>>
>> If you ask ME, I’d like to see us be able to use as much of C++ as specified in the GSL as possible in kernel-mode.
>>
>> I’d also REALLY like to see the evolution of the kernel programming interfaces to be C++ typedef’ed using GSL compliant types. Because, while I can do a lot of good by crafting the internal interfaces in my driver using safer types, until I can do the same with the various functions I call, we won’t have real safety. On this, I am not holding my breath.
>>
>> Peter
>> OSR
>>
>> (P.S. I was under the impression that it was indeed possible to get the MSFT STL working in kernel-mode, with exceptions basically causing a crash or something. Never having personally done that, I can’t swear this is correct, however).
>>
>>
>> —
>> 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:>

14

xxxxx@gmail.com wrote:

Now for writing the same stuff over and over for mundane C routines,
does not quite make me excited to write C++ stl. 'cause creating small
source library is all that needed.

Only if you’re writing small programs.  Once you have and trust the
incredible tools available in STL, you don’t have to worry about them
any more.  You can focus on the new and interesting problems in your
driver, without worrying about adapting yet another linked list or yet
another counted vector or yet another stack, AND you know that all the
iteration and manipulation routines you need will continue to work, even
if you change to another container.

STL provably saves programmer time, and that is a far more valuable
resource than many seem to think.

Even as recently as 2016, Ken Thomson also mentioned it is a overkill.
So that makes two famous peoples’ dislike. So it must be something …

You cannot be serious.  Your argument is exactly like those who say
“here are two scientists who say climate change is not human-caused,
therefore the 99,998 scientists who agree that it is human-caused must
be wrong.”

 

IMHO, it throws me off from the “Programmers Abstraction of the machine”.

Nonsense.  It’s just abstracting at a higher level.  I do not need to
worry about which registers are holding my linked list’s forward and
backward links.  I have more important things to do.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

15

>Ken Thomson also mentioned it is a overkill.

Good old Ken Thompson. I wonder how Plan 9 is doing these days? :wink:

Let’s agree two things about Mr. Thompson (whom I’ve never met, BTW):

  • He was an important innovator, back in the 1970’s

  • He’s an inventor of the Go programming language, which IMO is just about all you need to know about his stance on modern programming languages and development.

Peter
OSR
@OSRDrivers

16

For all the people who are going to quote experts, and for anyone else who
feels strongly one way of the other on C++, I strongly urge you to read “The
Design and Evolution of C++”. It is like sitting down with Bjarne in the
early days of the language before the known warts became “features”. If
someone wants to protest that claim, I was lucky enough to have the
opportunity to sit down in a group with Bjarne Stroustrup years ago.

If you read the book, you may well ask “How could he make these decisions?”
whether the answer is genius or idiot depends on the reader, and I have seen
people with strong opinions of the language flip their opinion after reading
the book. The books is available used from Amazon
https://www.amazon.com/Design-Evolution-C-Bjarne-Stroustrup/dp/0201543303/re
f=sr_1_1?ie=UTF8&qid=1516213529&sr=8-1&keywords=the+design+and+evolution+of+
c%2B%2B

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

17

Tim,

On the first paragraph, yes I understand about stl. In the past, iirc,
it was not very compatible.

For the second part, while he was interviewed after doing Gooooogle,
he said the same thing, perhaps to justify Go language. BTW, I had
little exposure to it, and personally I like it better than c++ :slight_smile:

Perhaps, your brain works better at a higher abstract layer ( class,
object, v pointers etc). I had too many abstract math, perhaps they
fried my brain, if I had any :slight_smile:

But for sure not at the register level. C really does not force you
think at that level ( first portable language widely popular for
different arch !)

-Pro

On Wed, Jan 17, 2018 at 9:59 AM, xxxxx@probo.com wrote:
> xxxxx@gmail.com wrote:
>> Now for writing the same stuff over and over for mundane C routines,
>> does not quite make me excited to write C++ stl. ‘cause creating small
>> source library is all that needed.
>
> Only if you’re writing small programs. Once you have and trust the
> incredible tools available in STL, you don’t have to worry about them
> any more. You can focus on the new and interesting problems in your
> driver, without worrying about adapting yet another linked list or yet
> another counted vector or yet another stack, AND you know that all the
> iteration and manipulation routines you need will continue to work, even
> if you change to another container.
>
> STL provably saves programmer time, and that is a far more valuable
> resource than many seem to think.
>
>
>> Even as recently as 2016, Ken Thomson also mentioned it is a overkill.
>> So that makes two famous peoples’ dislike. So it must be something …
>
> You cannot be serious. Your argument is exactly like those who say
> “here are two scientists who say climate change is not human-caused,
> therefore the 99,998 scientists who agree that it is human-caused must
> be wrong.”
>
>
>> IMHO, it throws me off from the “Programmers Abstraction of the machine”.
>
> Nonsense. It’s just abstracting at a higher level. I do not need to
> worry about which registers are holding my linked list’s forward and
> backward links. I have more important things to do.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> 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:>

18

“But for sure not at the register level. C really does not force you think at that level ( first portable language widely popular for different arch !)”

It was far from portable in the early days, and there were other languages that were as portable in the same era. The problem with C is it does expose the architecture of the system to a large degree. I suffered through the nightmares of helping port Unix to a number of platforms that did not look like PDP-11’s. The language was a pain because not everyone had byte pointers, the joys of little endian versus big endian when people typecast, and a number of other smaller annoyances.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

19

>> Good old Ken Thompson. I wonder how Plan 9 is doing these days? :wink:

I think it is still a research/prototype OS!

For Go, I had to play with it and iirc, it took quite a few features
from modern languages, including python. What I remember is that the
environment setting is different ( I would say more secure ), but I
lost the context now.

NB: if anyone knows a good seminar on Compiler, pls le’me know.
-Pro

On Wed, Jan 17, 2018 at 10:10 AM, xxxxx@osr.com wrote:
>>Ken Thomson also mentioned it is a overkill.
>
> Good old Ken Thompson. I wonder how Plan 9 is doing these days? :wink:
>
> Let’s agree two things about Mr. Thompson (whom I’ve never met, BTW):
>
> - He was an important innovator, back in the 1970’s
>
> - He’s an inventor of the Go programming language, which IMO is just about all you need to know about his stance on modern programming languages and development.
>
> 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:>

20

Point taken, Don.

What other language was quite portable at that time, at that level ?
Asking to hear from horses mouth :slight_smile:

-pro

On Wed, Jan 17, 2018 at 11:19 AM, xxxxx@windrvr.com wrote:
> “But for sure not at the register level. C really does not force you think at that level ( first portable language widely popular for different arch !)”
>
> It was far from portable in the early days, and there were other languages that were as portable in the same era. The problem with C is it does expose the architecture of the system to a large degree. I suffered through the nightmares of helping port Unix to a number of platforms that did not look like PDP-11’s. The language was a pain because not everyone had byte pointers, the joys of little endian versus big endian when people typecast, and a number of other smaller annoyances.
>
>
> Don Burn
> Windows Driver Consulting
> Website: http://www.windrvr.com
>
>
>
>
>
>
> —
> 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:>