Modern C++ Features in Kernel Mode Drivers

NTDEV
21

Using C++ as a better C has been a point of contention for decades. C++
gives you some strong type checking, and is better at finding dumb mistakes
that may have slipped by in C. I did a little C++ in a driver to see how it
felt. The driver filtered multiple device object types, so when creating my
device extension, I was able to create a base extension class for filters
that handled the basic filtering stuff, and then created inherited device
extension would contain device specific information. It was neat. I’ve just
never felt the need to do anything more using C++ in the kernel.

And no discussion thread on C vs. C++ would be complete without Linus’s
famous rant from 2007:

“C++ is a horrible language. It’s made more horrible by the fact that a lot
of substandard programmers use it, to the point where it’s much much easier
to generate total and utter crap with it. Quite frankly, even if the choice
of C were to do *nothing* but keep the C++ programmers out, that in itself
would be a huge reason to use C.” - LT

On Sat, Jul 7, 2018 at 12:41 PM xxxxx@hotmail.com <
xxxxx@lists.osr.com> wrote:

OMG…

I just don’t believe my own eyes. Am I hallucinating or what???

In other words, it looks like the list of “good coding guidelines”, as
well as " recommended practices", is about to get extended well beyond
using KMDF and inverted calls, pretty shortly. In fact, I would not get too
much surprised if certain posters who were not so long ago were speaking
the following way

start claiming, once in a sudden, that “using C++ is the only blessed way
to do things”

Anton Bassov

NTDEV is sponsored by OSR

Visit the list online at: <
http://www.osronline.com/showlists.cfm?list=ntdev\>

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://www.osronline.com/page.cfm?name=ListServer&gt;
>

–
Jamey Kirby
Disrupting the establishment since 1964

This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.</http:>

22

You know, I mentioned this exactly 10 to 15 years ago, perhaps as a reaction to Alberto’s famous rant about ASM or Peter’s liking of C# :slight_smile:

Functional programming is a powerful tool back in 90s to have proof systems. Of course Kenith Iverson came Weill before with APL :-).

Trusted computing group, as I know, looks at those languages, many because of proof system. I no longer know enough, if there is any effort to have systems implemented using functional programming languages. May be not PRACTICAL !!

But staying on this current thread, I mentioned because Peter loves to see C# :-). Need to avoid departure from the main topic.

I see people screaming about what a beautiful feathers being added to C++ in modern days, and how can you live with C ???

And most kernel codes are still in C, only C, nothing but C :-).

Sure there are some advantages! Was it worth considering ? Is the question.

Like Agile people always thinks — stand up and say your right. Otherwise projects are bound to fail. Then who know how to follow system will create but load of tickets to show they are working really hard.

Coding styles comes from people, I’ve seen easily can create a functions or two with more than 1000 lines, then preach do not use the following format —-

If( cond ) {
<…>
}else{
<…>
}

But use —
If ( cond)
{
<…>
}
Else
{
<…>
}

These are lack of SANITY when they come up with ideas ( when they don’t care about basic senate of software design, like any engineering ).

Then there are people - never hard of Big endian, Aligned memory etc., would come and say I will port your kernel code to C++, more reliable.

I’ve lived, and been living thru this. So it is not surprising some will come with — I’ve a library and publications that will help you code in C++ in the kernel. Oh, BTW only exception safe code can be used …. Dude, kill me now :slight_smile:

-Pro

On Jul 7, 2018, at 9:55 AM, xxxxx@hotmail.com wrote:
>
>> Basically, the Platform owner has to push. How about C# ?? Or Java ?? Or Go ??
>
>
>
> I would rather suggest Haskel - test your code once, and if it works, it is going to work in 100% of cases, without any possibility of a random bug that reveals itself only once in a while. Sounds fantastic, don’t you think…
>
>
>
>
>
> Anton Bassov
>
> —
> 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:>

23

Using C++ as a better C; Ok, I can almost buy that argument. I think it
comes down to the developer, and getting the job done. I worked on a
project where another company was contracted to write a NT 4.0 miniport for
a new SCSI controller. The company worked on it for two years, and was
under threat of a lawsuit because they could not get their driver working.
I was called in to take over the project. I spent 3 days (20+ hour days)
digging in to the 500 page spec., and looking over the existing code.

The developers were known for their SCSI knowledge, and had worked on many
other SCSI projects. They tried to reuse a lot of that old code. Most of it
was related to bus arbitration, and phase changes. The retail driver binary
was about 89K. I soon realized that the controller had meta commands. Setup
up for DMA, set up your parameter values, and ask the controller to send
data to the target (the controller handled all of the bus arbitration,
message phase, status phase, etc…). After three days, I had the driver
retail binary down to 4K (that was as small as a driver could be.) Checking
the map file, I had about 1200 bytes of code and something like 48 bytes of
data. I could have very well written that driver in ASM and made it
smaller, and faster. But, C is nearly as efficient as ASM, the driver was
screaming fast, and the customer was happy.

So, in that case 1) code reuse was BAD, 2) I barely needed C, C++ would
have just been silly.

We face different problems in the kernel. Problems that you really don’t
solve using C++. Shoot me or whatever, maybe it is just because I am
old-school when it come to the kernel. On the flipside, I am really digging
node.js and lambda like cloud functions. :slight_smile:

On Sat, Jul 7, 2018 at 1:16 PM xxxxx@gmail.com
wrote:

> You know, I mentioned this exactly 10 to 15 years ago, perhaps as a
> reaction to Alberto’s famous rant about ASM or Peter’s liking of C# :slight_smile:
>
> Functional programming is a powerful tool back in 90s to have proof
> systems. Of course Kenith Iverson came Weill before with APL :-).
>
> Trusted computing group, as I know, looks at those languages, many because
> of proof system. I no longer know enough, if there is any effort to have
> systems implemented using functional programming languages. May be not
> PRACTICAL !!
>
> But staying on this current thread, I mentioned because Peter loves to see
> C# :-). Need to avoid departure from the main topic.
>
> I see people screaming about what a beautiful feathers being added to C++
> in modern days, and how can you live with C ???
>
> And most kernel codes are still in C, only C, nothing but C :-).
>
> Sure there are some advantages! Was it worth considering ? Is the question.
>
> Like Agile people always thinks — stand up and say your right. Otherwise
> projects are bound to fail. Then who know how to follow system will create
> but load of tickets to show they are working really hard.
>
> Coding styles comes from people, I’ve seen easily can create a functions
> or two with more than 1000 lines, then preach do not use the following
> format —-
>
> If( cond ) {
> <…>
> }else{
> <…>
> }
>
> But use —
> If ( cond)
> {
> <…>
> }
> Else
> {
> <…>
> }
>
> These are lack of SANITY when they come up with ideas ( when they don’t
> care about basic senate of software design, like any engineering ).
>
> Then there are people - never hard of Big endian, Aligned memory etc.,
> would come and say I will port your kernel code to C++, more reliable.
>
> I’ve lived, and been living thru this. So it is not surprising some will
> come with — I’ve a library and publications that will help you code in C++
> in the kernel. Oh, BTW only exception safe code can be used …. Dude, kill
> me now :slight_smile:
>
> -Pro
>
>
>
> > On Jul 7, 2018, at 9:55 AM, xxxxx@hotmail.com <
> xxxxx@lists.osr.com> wrote:
> >
> >> Basically, the Platform owner has to push. How about C# ?? Or Java ??
> Or Go ??
> >
> >
> >
> > I would rather suggest Haskel - test your code once, and if it works, it
> is going to work in 100% of cases, without any possibility of a random bug
> that reveals itself only once in a while. Sounds fantastic, don’t you
> think…
> >
> >
> >
> >
> >
> > Anton Bassov
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev&gt;
> >
> > 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://www.osronline.com/page.cfm?name=ListServer&gt;
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev&gt;
>
> 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://www.osronline.com/page.cfm?name=ListServer&gt;
>

–
Jamey Kirby
Disrupting the establishment since 1964

This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.</http:></http:>

24

This is as good an example, as I would bye without any hesitation :-). I’ve seen few C++ windows kernel driver, at the FS filter level, well before WDF/KMDF. Did they ever fly? Not really.

In user mode, as I said, I used many of the C++ features, and on my days - I can get the crap out of it using gdb/lldb or Windbg. Also around 2005 I wanted to read the design behind C++, and never seen any place it is targeting kernel. It was all about large system software. IMO that is where the daemons/services lives…

One of the daemon, I handle sometime is over 80 to 90K C code. And that is where I do the redesign, whenever I get a chance. For example, coming up with a C++ interface and give to 3rd party to implement those interfaces in C++ ( they love C++ :slight_smile: ), and I can provide c to C++ interface. What I get is to dynamically support many libraries ( just short of IUNKnown () :-). So there is a conscious support to make it C++ where it is needed.

Same with the other infrastructure I mentioned earlier. I took these kind of risk/effort - first to give junior and intermediate engineers to take ownership and something they can put their teeth on, second ownership delegation…

When I do trap like thermal APIC interrupt, or stay on top of VFS or if needed do a blind kernel stack walk on released kernel, etc. I go for C, and not afraid to use ASM. And these things goes to many ( really large) users…

I don’t think it is old mentality ! It is just - experiences taught us what tools to use when needed .

For those in the teaching business, I can understand how important to be C++/Java to be relevant, since most college and university don’t deal much with low levels .

BTW:: I’ve said earlier, and now gain , if some one can refer to an exceptional compiler seminar that would cover modern compiler technology, that would be of real help :slight_smile:

-Pro

On Jul 7, 2018, at 11:11 AM, xxxxx@gmail.com wrote:
>
> Using C++ as a better C; Ok, I can almost buy that argument. I think it comes down to the developer, and getting the job done. I worked on a project where another company was contracted to write a NT 4.0 miniport for a new SCSI controller. The company worked on it for two years, and was under threat of a lawsuit because they could not get their driver working. I was called in to take over the project. I spent 3 days (20+ hour days) digging in to the 500 page spec., and looking over the existing code.
>
> The developers were known for their SCSI knowledge, and had worked on many other SCSI projects. They tried to reuse a lot of that old code. Most of it was related to bus arbitration, and phase changes. The retail driver binary was about 89K. I soon realized that the controller had meta commands. Setup up for DMA, set up your parameter values, and ask the controller to send data to the target (the controller handled all of the bus arbitration, message phase, status phase, etc…). After three days, I had the driver retail binary down to 4K (that was as small as a driver could be.) Checking the map file, I had about 1200 bytes of code and something like 48 bytes of data. I could have very well written that driver in ASM and made it smaller, and faster. But, C is nearly as efficient as ASM, the driver was screaming fast, and the customer was happy.
>
> So, in that case 1) code reuse was BAD, 2) I barely needed C, C++ would have just been silly.
>
> We face different problems in the kernel. Problems that you really don’t solve using C++. Shoot me or whatever, maybe it is just because I am old-school when it come to the kernel. On the flipside, I am really digging node.js and lambda like cloud functions. :slight_smile:
>
>
> On Sat, Jul 7, 2018 at 1:16 PM xxxxx@gmail.com mailto:xxxxx > wrote:
> You know, I mentioned this exactly 10 to 15 years ago, perhaps as a reaction to Alberto’s famous rant about ASM or Peter’s liking of C# :slight_smile:
>
> Functional programming is a powerful tool back in 90s to have proof systems. Of course Kenith Iverson came Weill before with APL :-).
>
> Trusted computing group, as I know, looks at those languages, many because of proof system. I no longer know enough, if there is any effort to have systems implemented using functional programming languages. May be not PRACTICAL !!
>
> But staying on this current thread, I mentioned because Peter loves to see C# :-). Need to avoid departure from the main topic.
>
> I see people screaming about what a beautiful feathers being added to C++ in modern days, and how can you live with C ???
>
> And most kernel codes are still in C, only C, nothing but C :-).
>
> Sure there are some advantages! Was it worth considering ? Is the question.
>
> Like Agile people always thinks — stand up and say your right. Otherwise projects are bound to fail. Then who know how to follow system will create but load of tickets to show they are working really hard.
>
> Coding styles comes from people, I’ve seen easily can create a functions or two with more than 1000 lines, then preach do not use the following format —-
>
> If( cond ) {
> <…>
> }else{
> <…>
> }
>
> But use —
> If ( cond)
> {
> <…>
> }
> Else
> {
> <…>
> }
>
> These are lack of SANITY when they come up with ideas ( when they don’t care about basic senate of software design, like any engineering ).
>
> Then there are people - never hard of Big endian, Aligned memory etc., would come and say I will port your kernel code to C++, more reliable.
>
> I’ve lived, and been living thru this. So it is not surprising some will come with — I’ve a library and publications that will help you code in C++ in the kernel. Oh, BTW only exception safe code can be used …. Dude, kill me now :slight_smile:
>
> -Pro
>
>
>
> > On Jul 7, 2018, at 9:55 AM, xxxxx@hotmail.com mailto:xxxxx > wrote:
> >
> >> Basically, the Platform owner has to push. How about C# ?? Or Java ?? Or Go ??
> >
> >
> >
> > I would rather suggest Haskel - test your code once, and if it works, it is going to work in 100% of cases, without any possibility of a random bug that reveals itself only once in a while. Sounds fantastic, don’t you think…
> >
> >
> >
> >
> >
> > Anton Bassov
> >
> > —
> > 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:>
>
>
> —
> 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:>
>
>
> –
> Jamey Kirby
> Disrupting the establishment since 1964
>
> This is a personal email account and as such, emails are not subject to archiving. Nothing else really matters.
> — NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at</http:></http:></http:></http:></http:></http:></mailto:xxxxx></mailto:xxxxx>

25

> And no discussion thread on C vs. C++ would be complete without Linus’s famous rant from 2007:

Well, when I referred to it few years ago (I think it was NTTALK) our host was so impressed with his attitude that he was promising “To buy Mr.Penguin pants a beers”. As you can see from his posts on this thread, things DO change with time…

Anton Bassov

26

For the third or so time: It’s NOT ABOUT OO. It’s not about the ability to derive classes from base classes. It’s about the ability to create safer code.

You are sounding like somebody who has not read the modern C++ standards.

Again… please see span, unique_ptr, RAII patterns, and their friends.

> I barely needed C, C++ would have just been silly.

Mr. Kirby, Mr. Kirby, Mr. Kirby… tsk, tsk, tsk…

You don’t need type safety? You don’t need protection against buffer over-runs? Against pointer arithmetic out of bounds?

It’s NOT ABOUT needing std::vector or std::tuple… though I’d dearly like those because I, for one, and sick and fucking tired of calling InsertTailList. It’s about the other features in the language, support for which in kernel mode I’ve been advocating.

Shit, even having access to the silly [[fallthrough]] attribute is better than what you get in C.

>famous rant from 2007

As I wrote a year ago, it SOUNDS like it was written in 2007 (more than TEN years ago)… and back in 2007 I agreed with him. C++ has changed since then. A lot. Enough to make it worth a second look.

>I just don’t believe my own eyes. Am I hallucinating or what???

Nurse! The patient in bed 9 needs his meds.

(enjoy it while you can, Mr. Bassov… Troll Mode is coming soon to a forum you love to troll)

Peter
OSR
@OSRDrivers

27

OH… I wanted to return to this:

The machine abstraction(s) are right there at C level ( no more / no less ).

Spoken like someone who has used high level languages his whole professional life.

If your content is that “C is merely a straight-forward abstraction of lower-level assembler principals” you are seriously mistaken. C plays tricks behind your back… all the time. If you’re an assembly language programmer, it’s SUPER hard to understand what the fuck it is doing. This is a particular hot button of mine:

foo = foo + 1;

Why on the LEFT of the equals sign does “foo” mean “the address foo” and on the RIGHT of the equals sign, “foo” means “the contents of the address foo” – To somebody whose first language is assembly, that is seriously messed up.

So… we have an abstraction with special rules for L-Values and R-Values and countless other things. It’s absolutely not “the machine abstraction is right there” – no way.

Peter
OSR
@OSRDrivers

28

No,

I’ve used quite a bit of assembly language. There is not much you want to know when not needed. Memory address, stack, dynamic memory are some of the basic abstractions I meant to say, as opposed to write a boot loader ( where your env., is just ASM). As I understand, this is programmers abstraction of machine ( sure ISA is more granular, then there are whole lot of other questions ).

Funny thing is, and electrical engineer said the same thing 30 years ago, when he was doing fortran.

What we do in the kernel rarely needs ASM, but can be used ( even with macros ), or leaf function these days. But not C++. Forget about L-value, R-value, forget about how that can mess up on multi-the function, forget about barrier, weak sequential consistency. They are not the topics here.

As I said, let’s get a WDK with only C++, and we will follow ( well of course when it comes to WDK ).

I hope C++ does not have an IDENTITY crisis :slight_smile:

-Pro

On Jul 7, 2018, at 2:35 PM, xxxxx@osr.com wrote:
>
> OH… I wanted to return to this:
>
>> The machine abstraction(s) are right there at C level ( no more / no less ).
>
> Spoken like someone who has used high level languages his whole professional life.
>
> If your content is that “C is merely a straight-forward abstraction of lower-level assembler principals” you are seriously mistaken. C plays tricks behind your back… all the time. If you’re an assembly language programmer, it’s SUPER hard to understand what the fuck it is doing. This is a particular hot button of mine:
>
> foo = foo + 1;
>
> Why on the LEFT of the equals sign does “foo” mean “the address foo” and on the RIGHT of the equals sign, “foo” means “the contents of the address foo” – To somebody whose first language is assembly, that is seriously messed up.
>
> So… we have an abstraction with special rules for L-Values and R-Values and countless other things. It’s absolutely not “the machine abstraction is right there” – no way.
>
> 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:>

29

> enjoy it while you can, Mr. Bassov… Troll Mode is coming soon to a forum you love to troll

Actually, these days I am trying to behave exactly because of the fear of above mentioned “scary” feature, but this is C++ thread so that at least some trolling should be permitted on it, don’t you think…

BTW, once we are at it, the quotation that I had provided earlier was taken from the classic C++ thread where Mr.Kyler made his historic speech…

As I wrote a year ago, it SOUNDS like it was written in 2007 (more than TEN years ago)…
and back in 2007 I agreed with him. C++ has changed since then. A lot. Enough to make
it worth a second look.

Well, C++ has always had at least some good features like strong type checking and inline functions instead of ugly C macros. In fact, the latter one even made its way into C via C99 standard. However, it does not necessarily imply that kernel-mode programmers should "take the full advantage"of all the ugly, cumbersome and unwieldy features that it offers. For example, do you really need multiple inheritance and operator overload in your drivers???

Would not it be better just to develop some non-standard C+±inspired compiler extensions to C that can be enabled/disabled via compiler switch/argument, effectively borrowing certain good features from C++ while leaving all its cumbersome and unwieldy ones (i.e 90+% of the language) behind?

Anton Bassov

30

Now in the days of Alternative facts, it is hard to belief any news, but heck why not look at some sample sites ???

https://stackify.com/popular-programming-languages-2018/ https:</https:>

Gives some stats about % use of languages …

-Pro

On Jul 7, 2018, at 3:27 PM, xxxxx@gmail.com wrote:
>
> No,
>
> I’ve used quite a bit of assembly language. There is not much you want to know when not needed. Memory address, stack, dynamic memory are some of the basic abstractions I meant to say, as opposed to write a boot loader ( where your env., is just ASM). As I understand, this is programmers abstraction of machine ( sure ISA is more granular, then there are whole lot of other questions ).
>
> Funny thing is, and electrical engineer said the same thing 30 years ago, when he was doing fortran.
>
> What we do in the kernel rarely needs ASM, but can be used ( even with macros ), or leaf function these days. But not C++. Forget about L-value, R-value, forget about how that can mess up on multi-the function, forget about barrier, weak sequential consistency. They are not the topics here.
>
> As I said, let’s get a WDK with only C++, and we will follow ( well of course when it comes to WDK ).
>
> I hope C++ does not have an IDENTITY crisis :slight_smile:
>
> -Pro
>
>> On Jul 7, 2018, at 2:35 PM, xxxxx@osr.com wrote:
>>
>> OH… I wanted to return to this:
>>
>>> The machine abstraction(s) are right there at C level ( no more / no less ).
>>
>> Spoken like someone who has used high level languages his whole professional life.
>>
>> If your content is that “C is merely a straight-forward abstraction of lower-level assembler principals” you are seriously mistaken. C plays tricks behind your back… all the time. If you’re an assembly language programmer, it’s SUPER hard to understand what the fuck it is doing. This is a particular hot button of mine:
>>
>> foo = foo + 1;
>>
>> Why on the LEFT of the equals sign does “foo” mean “the address foo” and on the RIGHT of the equals sign, “foo” means “the contents of the address foo” – To somebody whose first language is assembly, that is seriously messed up.
>>
>> So… we have an abstraction with special rules for L-Values and R-Values and countless other things. It’s absolutely not “the machine abstraction is right there” – no way.
>>
>> 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:
>
>
> —
> 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:></http:></http:>

31

> James Kirby said:

LARGE_INTEGER x = { .QuadPart = 1000000 };
to me is better than
LARGE_INTEGER x;
x.QuadPart = 1000000;
The former is not allowed in C++

c++20 is adding designated initializers. So I bet this fills you with joy right? However I must say the code you advocate looks hideous and archaic to me. Without totally blowing anyone’s mind I’ll stop a little short of the elegance that I’d rather write to give some idea:

MyEvent.Wait(milliseconds(100));

No LARGE_INTEGER nonsense definitions. No magic number with a bunch zero’s nonsense for timing with no tricky +/- sign making it absolute/relative nonsense. No long tired nonsense argument lists to KeWaitForSingleObject. So rather than having to stop and spend time and brain power analyzing tricky, error prone, garbage looking code the developer needs just a quick glance and moves on to other more important parts of the project.

32

Simply because the name “foo” on the left and the right sides of the assignment refers to respectively destination and source operands that do not necessarily have to be the same, although they happen to be in this particular case.

As long as you are speaking about x86 assembly programmer, he may find it a bit confusing because x86 instruction set request one of the two source operands to be a destination one as well, so that he does not really understand why the assignment statement is needed, in the first place. From his perspective, a statement like “foo +1” alone should suffice in order to do the addition.

However, if our imaginary assembly programmer works with an architecture where you have two source operands and a destination one for every math/logic operation (like, say, RISCV) there is nothing even remotely confusing for him. In fact, for the reasons of clarity his assembly language may even offer basically the same syntax as C does, for example, like “R1 eq R2 ADD R3”

Anton Bassov

33

>

Would not it be better just to develop some non-standard C+±inspired compiler extensions to C that can be enabled/disabled via compiler switch/argument, effectively borrowing certain good features from C++ while leaving all its cumbersome and unwieldy ones (i.e 90+% of the language) behind?

This sounds like the way to go, be pragmatic !

-Pro

On Jul 7, 2018, at 3:43 PM, xxxxx@hotmail.com wrote:
>
>
> Would not it be better just to develop some non-standard C+±inspired compiler extensions to C that can be enabled/disabled via compiler switch/argument, effectively borrowing certain good features from C++ while leaving all its cumbersome and unwieldy ones (i.e 90+% of the language) behind?

34

My point wasn’t about LARGE_INTEGER, you can initialize any data structure
this way. I just jotted down LARGE_INTEGER as a quick and simple example.
As for being archaic; no more archaic than int x = 0;

I concede on stronger type checking, and using C++ as a better C in some
cases. I’m going to stick with C for a while longer, and we’ll see what MS
does on the WDK side before seriously considering switching to building in
CPP mode.

On Sat, Jul 7, 2018 at 9:32 PM xxxxx@hotmail.com
wrote:

>


>
> Simply because the name “foo” on the left and the right sides of the
> assignment refers to respectively destination and source operands that do
> not necessarily have to be the same, although they happen to be in this
> particular case.
>
> As long as you are speaking about x86 assembly programmer, he may find it
> a bit confusing because x86 instruction set request one of the two source
> operands to be a destination one as well, so that he does not really
> understand why the assignment statement is needed, in the first place. From
> his perspective, a statement like “foo +1” alone should suffice in order to
> do the addition.
>
>
> However, if our imaginary assembly programmer works with an architecture
> where you have two source operands and a destination one for every
> math/logic operation (like, say, RISCV) there is nothing even remotely
> confusing for him. In fact, for the reasons of clarity his assembly
> language may even offer basically the same syntax as C does, for example,
> like “R1 eq R2 ADD R3”
>
>
> Anton Bassov
>
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev&gt;
>
> 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://www.osronline.com/page.cfm?name=ListServer&gt;
>

–
Jamey Kirby
Disrupting the establishment since 1964

This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.</http:>

35

> My point wasn’t about LARGE_INTEGER, you can initialize any data structure this way.

Yes I’ve always liked this type of member initialization too, but C++ is more focused on putting the flexibility on the side of the designer of a type so designers can make it easy to use a type correctly and difficult to use it incorrectly. So exposing something like a QuadPart member would be a mistake when a simple assignment (eg: LARGE_INTEGER x = 100000) would be preferred by all.

LARGE_INTEGER and its QuadPart is a great example of how things can go wrong with the C way of thinking where C++ would have been a breeze. This whole fiasco started when there was no 64-bit data type in the compiler. The designers at that time used C to create the LARGE_INTEGER monstrosity. It’s ugly, painful, and worst of all was totally avoidable yet here we are 20 years later stuck with this mess. And as I alluded to, why do we even have to instantiate it at all when 99% of the time we just want a simple literal parameter? And all the magic numbers, +/- prefix? It’s all head shakingly dumb.

36

In a perfect world, many things such as this might be possible. In a perfect world, we’d design a whole new language. But it’s not *practical* and it’s not going to happen.

The closest thing that’s likely to happen is the INVERSE of what you’re suggesting, and that’s to standardize a SUBSET of C++ features that are suitable for use in the kernel or for embedded programming, so one can count on them being available. This is Mr. Craig’s (SC22 WG21 SG14) proposal.

The OS is written almost entirely in C. Most of us recognize that C has a number of deficiencies. The only reason we’re even TALKING about C++ is that a you get support for a subset of C++ “for free” in VS and in the OS.

So, the argument is *what subset* gets supported, when, and by whom.

Peter
OSR
@OSRDrivers

37

> In a perfect world, many things such as this might be possible. In a perfect world,

we’d design a whole new language. But it’s not *practical* and it’s not going to happen.

In fact, the whole task is not as daunting as it may seem at the first glance. Don’t forget that all these extensions are already there, and get enabled/disabled by switching between .cpp and .c file extensions. The problem is that it enables/disables a way too many features in one go. What I am speaking about is trying to do it in more “fine-grained” fashion and with more control given to a programmer,i.e. doing it exactly the same way it is done with compiler optimisations - we can decide which of them we want, and pass a corresponding argument to the compiler. Would not it be a good idea to give a programmer a chance to decide and control which C++ features can get compiled in a file with .c extension? It can even be made to work at multiple levels, i.e., again, the same way it works with optimisation,

This task is, indeed, daunting. In order to see how complex it is all you have to do is to check any C+±related thread on NTDEV - it invariably ends up in a flame war. Do you really think that it is
going to be easy to find a consensus here???

Another point to consider is that the code for kernel-mode and embedded development is not meant to be easily portable across different projects, in the first place. Every system has its own kernel-mode API and system architecture, and there are no standards here, including even support for C runtime. At this point one may start questioning the practical usefulness of such a standard, in the first place.

So, the argument is *what subset* gets supported, when, and by whom.

I hope you can agree now that my suggestion is anything but idealistic - it eliminates the above dilemma right on the spot by giving the full control to a programmer. The “only” question is how hard it is, from the compiler guy’s perspective, to implement this feature…

Anton Bassov

38

Slashdot posted an article on C++ yesterday titled "Is C++ a ‘Really
Terrible Language?’ referenced here:
https://developers.slashdot.org/story/18/07/07/0342201/is-c-a-really-terrible-language

Slashdot posted this article on their twitter feed here (check out the top
response to the tweet):
https://twitter.com/slashdot/status/1015741333724524545

Hahahahaha!

On Sun, Jul 8, 2018 at 2:42 PM xxxxx@hotmail.com
wrote:

> > In a perfect world, many things such as this might be possible. In a
> perfect world,
> > we’d design a whole new language. But it’s not practical and it’s not
> going to happen.
>
>
> In fact, the whole task is not as daunting as it may seem at the first
> glance. Don’t forget that all these extensions are already there, and get
> enabled/disabled by switching between .cpp and .c file extensions. The
> problem is that it enables/disables a way too many features in one go. What
> I am speaking about is trying to do it in more “fine-grained” fashion and
> with more control given to a programmer,i.e. doing it exactly the same way
> it is done with compiler optimisations - we can decide which of them we
> want, and pass a corresponding argument to the compiler. Would not it be a
> good idea to give a programmer a chance to decide and control which C++
> features can get compiled in a file with .c extension? It can even be made
> to work at multiple levels, i.e., again, the same way it works with
> optimisation,
>
>
>
>


>
> This task is, indeed, daunting. In order to see how complex it is all you
> have to do is to check any C+±related thread on NTDEV - it invariably ends
> up in a flame war. Do you really think that it is
> going to be easy to find a consensus here???
>
>
> Another point to consider is that the code for kernel-mode and embedded
> development is not meant to be easily portable across different projects,
> in the first place. Every system has its own kernel-mode API and system
> architecture, and there are no standards here, including even support for C
> runtime. At this point one may start questioning the practical usefulness
> of such a standard, in the first place.
>
>
> > So, the argument is what subset gets supported, when, and by whom.
>
>
> I hope you can agree now that my suggestion is anything but idealistic -
> it eliminates the above dilemma right on the spot by giving the full
> control to a programmer. The “only” question is how hard it is, from the
> compiler guy’s perspective, to implement this feature…
>
>
> Anton Bassov
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev&gt;
>
> 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://www.osronline.com/page.cfm?name=ListServer&gt;
>

–
Jamey Kirby
Disrupting the establishment since 1964

This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.</http:>

39

Even Grady Booch is in on the tweets. That tweet brought out the heavy
hitters.

On Sun, Jul 8, 2018 at 3:13 PM Jamey Kirby wrote:

> Slashdot posted an article on C++ yesterday titled "Is C++ a ‘Really
> Terrible Language?’ referenced here:
>
> https://developers.slashdot.org/story/18/07/07/0342201/is-c-a-really-terrible-language
>
> Slashdot posted this article on their twitter feed here (check out the top
> response to the tweet):
> https://twitter.com/slashdot/status/1015741333724524545
>
> Hahahahaha!
>
>
> On Sun, Jul 8, 2018 at 2:42 PM xxxxx@hotmail.com <
> xxxxx@lists.osr.com> wrote:
>
>> > In a perfect world, many things such as this might be possible. In a
>> perfect world,
>> > we’d design a whole new language. But it’s not practical and it’s not
>> going to happen.
>>
>>
>> In fact, the whole task is not as daunting as it may seem at the first
>> glance. Don’t forget that all these extensions are already there, and get
>> enabled/disabled by switching between .cpp and .c file extensions. The
>> problem is that it enables/disables a way too many features in one go. What
>> I am speaking about is trying to do it in more “fine-grained” fashion and
>> with more control given to a programmer,i.e. doing it exactly the same way
>> it is done with compiler optimisations - we can decide which of them we
>> want, and pass a corresponding argument to the compiler. Would not it be a
>> good idea to give a programmer a chance to decide and control which C++
>> features can get compiled in a file with .c extension? It can even be made
>> to work at multiple levels, i.e., again, the same way it works with
>> optimisation,
>>
>>
>>
>>


>>
>> This task is, indeed, daunting. In order to see how complex it is all you
>> have to do is to check any C+±related thread on NTDEV - it invariably ends
>> up in a flame war. Do you really think that it is
>> going to be easy to find a consensus here???
>>
>>
>> Another point to consider is that the code for kernel-mode and embedded
>> development is not meant to be easily portable across different projects,
>> in the first place. Every system has its own kernel-mode API and system
>> architecture, and there are no standards here, including even support for C
>> runtime. At this point one may start questioning the practical usefulness
>> of such a standard, in the first place.
>>
>>
>> > So, the argument is what subset gets supported, when, and by whom.
>>
>>
>> I hope you can agree now that my suggestion is anything but idealistic -
>> it eliminates the above dilemma right on the spot by giving the full
>> control to a programmer. The “only” question is how hard it is, from the
>> compiler guy’s perspective, to implement this feature…
>>
>>
>> Anton Bassov
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list online at: <
>> http://www.osronline.com/showlists.cfm?list=ntdev&gt;
>>
>> 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://www.osronline.com/page.cfm?name=ListServer&gt;
>>
>
>
> –
> Jamey Kirby
> Disrupting the establishment since 1964
>
> This is a personal email account and as such, emails are not subject to
> archiving. Nothing else really matters.
>

–
Jamey Kirby
Disrupting the establishment since 1964

This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.</http:>

40

Thanks for sharing the link, quite entertaining :-).

I just glanced thru the Guideline, quite a bit of interesting thing, and some silly examples.

In the section of resource leak, due to using FILE * fp = ….; and returning in the middle without closing the file.

It encourages someone to do multiple point of returns, that imply that all thing are on stack, and don’t worry. Once I want to have dynamic memory, the recourse seems to push it down to .

We all figured that one point of return is always preferable for this reason, wrap the logic with do{ […] }while(0); or some such. If a condition fail, break it.

But I’m sure the GuideLine will help me for my own development …

-Pro

> On Jul 8, 2018, at 12:13 PM, xxxxx@gmail.com wrote:
>
> Slashdot posted an article on C++ yesterday titled "Is C++ a ‘Really Terrible Language?’ referenced here:
> https://developers.slashdot.org/story/18/07/07/0342201/is-c-a-really-terrible-language https:
>
> Slashdot posted this article on their twitter feed here (check out the top response to the tweet):
> https://twitter.com/slashdot/status/1015741333724524545 https:
>
> Hahahahaha!
>
>
> On Sun, Jul 8, 2018 at 2:42 PM xxxxx@hotmail.com mailto:xxxxx > wrote:
> > In a perfect world, many things such as this might be possible. In a perfect world,
> > we’d design a whole new language. But it’s not practical and it’s not going to happen.
>
>
> In fact, the whole task is not as daunting as it may seem at the first glance. Don’t forget that all these extensions are already there, and get enabled/disabled by switching between .cpp and .c file extensions. The problem is that it enables/disables a way too many features in one go. What I am speaking about is trying to do it in more “fine-grained” fashion and with more control given to a programmer,i.e. doing it exactly the same way it is done with compiler optimisations - we can decide which of them we want, and pass a corresponding argument to the compiler. Would not it be a good idea to give a programmer a chance to decide and control which C++ features can get compiled in a file with .c extension? It can even be made to work at multiple levels, i.e., again, the same way it works with optimisation,
>
>
>
>


>
> This task is, indeed, daunting. In order to see how complex it is all you have to do is to check any C+±related thread on NTDEV - it invariably ends up in a flame war. Do you really think that it is
> going to be easy to find a consensus here???
>
>
> Another point to consider is that the code for kernel-mode and embedded development is not meant to be easily portable across different projects, in the first place. Every system has its own kernel-mode API and system architecture, and there are no standards here, including even support for C runtime. At this point one may start questioning the practical usefulness of such a standard, in the first place.
>
>
> > So, the argument is what subset gets supported, when, and by whom.
>
>
> I hope you can agree now that my suggestion is anything but idealistic - it eliminates the above dilemma right on the spot by giving the full control to a programmer. The “only” question is how hard it is, from the compiler guy’s perspective, to implement this feature…
>
>
> Anton Bassov
>
>
>
> —
> 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:>
>
>
> –
> Jamey Kirby
> Disrupting the establishment since 1964
>
> This is a personal email account and as such, emails are not subject to archiving. Nothing else really matters.
> — NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at</http:></http:></http:></mailto:xxxxx></https:></https:>