Modern C++ Features in Kernel Mode Drivers

Prokash_Sinha · July 7, 2018, 6:28pm

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

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

anton_bassov · July 7, 2018, 6:43pm

> 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

Prokash_Sinha-1 · July 7, 2018, 6:58pm

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

Sven_Kreamer · July 7, 2018, 9:25pm

> 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.

anton_bassov · July 7, 2018, 9:32pm

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

Prokash_Sinha · July 7, 2018, 10:51pm

>

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?

Jamey_Kirby · July 7, 2018, 10:52pm

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

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

Sven_Kreamer · July 8, 2018, 1:58am

> 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.

Peter_Viscarola_OSR · July 8, 2018, 10:16am

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

anton_bassov · July 8, 2018, 2:42pm

> 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

Jamey_Kirby · July 8, 2018, 3:14pm

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

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

Jamey_Kirby · July 8, 2018, 3:37pm

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

Prokash_Sinha-1 · July 8, 2018, 6:29pm

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

Sven_Kreamer · July 8, 2018, 8:23pm

Again some of you have done a great job articulating that dumb people make dumb c++ code. All the while never wanting to remotely discuss the fact that dumb people make dumb C code: eat the stack, spaghetti, buggy, misused, unreadable. So what is your point exactly? And you can see in his quote that even linus understands that substandard programmers are the problem not the c++ language. Maybe here there are those that fit that description. I just don’t know why you would want to advertise that to everyone every chance you get.

Prokash_Sinha-1 · July 8, 2018, 9:06pm

I’m not seeing anyone calling C++ programmer dumb, at least here ! Everyone talking about getting to kernel. I don’t see anyone should be that sentimental about it !!!.

If you, direct this to me, let me tell you, I used take an Undergrad class at Duke for C++. I mentioned I worked on OS/2 C++, Microsoft C++, and open sour C++. Currently, just a month ago I came out of another project, where there is a sincere effort to make components sole based on C++. I also mentioned, I’m more into Design Patterns than just lookin at crono and dance around with explicitness, that is just not my cup of tea.

Shared pointer, unique pointer etc., I’ve used on many a times. Did throw away, pthread code, used C++ thread, but inside a design pattern.

I think some of us should look at the deeper problem. Search the internet, pls be self-critical and ask for once - Why dumb programmer are dump. MIT has good articles, search if you are curious :-). I’m not going to point that out.

All we are talking about is how to get the C++ best features into kernel.

I read the article, not thoroughly, as I mentioned earlier, and this are lot of silly examples. I think lot of us better things to do in life !

If you did not point to me, at least you should have the courage to tell who you think is unfairly telling C++ programmers dumb.

-Pro

On Jul 8, 2018, at 5:23 PM, xxxxx@gmail.com wrote:
>
> Again some of you have done a great job articulating that dumb people make dumb c++ code. All the while never wanting to remotely discuss the fact that dumb people make dumb C code: eat the stack, spaghetti, buggy, misused, unreadable. So what is your point exactly? And you can see in his quote that even linus understands that substandard programmers are the problem not the c++ language. Maybe here there are those that fit that description. I just don’t know why you would want to advertise that to everyone every chance you get.
>
>
> —
> 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:>

Prokash_Sinha-1 · July 8, 2018, 9:12pm

More over, I’m currently on a team to drive the x-platform C++ ( osx, Win10+, Linux ). And I don’t get scared to comment on bad style of C++ ( 11 ) versions, made others to change code at late stage.

-Pro

On Jul 8, 2018, at 6:05 PM, xxxxx@garlic.com wrote:
>
> I’m not seeing anyone calling C++ programmer dumb, at least here ! Everyone talking about getting to kernel. I don’t see anyone should be that sentimental about it !!!.
>
> If you, direct this to me, let me tell you, I used take an Undergrad class at Duke for C++. I mentioned I worked on OS/2 C++, Microsoft C++, and open sour C++. Currently, just a month ago I came out of another project, where there is a sincere effort to make components sole based on C++. I also mentioned, I’m more into Design Patterns than just lookin at crono and dance around with explicitness, that is just not my cup of tea.
>
> Shared pointer, unique pointer etc., I’ve used on many a times. Did throw away, pthread code, used C++ thread, but inside a design pattern.
>
> I think some of us should look at the deeper problem. Search the internet, pls be self-critical and ask for once - Why dumb programmer are dump. MIT has good articles, search if you are curious :-). I’m not going to point that out.
>
> All we are talking about is how to get the C++ best features into kernel.
>
> I read the article, not thoroughly, as I mentioned earlier, and this are lot of silly examples. I think lot of us better things to do in life !
>
> If you did not point to me, at least you should have the courage to tell who you think is unfairly telling C++ programmers dumb.
>
> -Pro
>
>
>
>> On Jul 8, 2018, at 5:23 PM, xxxxx@gmail.com wrote:
>>
>> Again some of you have done a great job articulating that dumb people make dumb c++ code. All the while never wanting to remotely discuss the fact that dumb people make dumb C code: eat the stack, spaghetti, buggy, misused, unreadable. So what is your point exactly? And you can see in his quote that even linus understands that substandard programmers are the problem not the c++ language. Maybe here there are those that fit that description. I just don’t know why you would want to advertise that to everyone every chance you get.
>>
>>
>> —
>> 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:>

Sven_Kreamer · July 8, 2018, 10:38pm

I believe anyone unable to find one single useful thing in c++ is dumb and/or obstinate. This is because c++ has a treasure chest of goods specifically for system level programming and more are being added all the time. It’s fantastic.

Let’s take one. Today when we express relative time quantities in the kernel it is in negative 100 nanosecond units. So if we want a 10 millisecond timeout the psuedo is like:

LARGE_INTEGER n;

n.QuadPart = -1000000; // programmers reaction: wtf is -100000?

KeWait(n); // programmers reaction: wth didn’t you just pass -100000 directly?

c++ allows adding things like microsecond and millisecond tags on literals. So we can write this instead:

KeWait(10ms); // programmers reaction: got it!

So tell me which way do you prefer, c or c++? and if the former can you articulate why? I’ll try not to fall off my chair laughing.

Jamey_Kirby · July 8, 2018, 10:45pm

LARGE_INTEGER n = { .QuadPart = SOME_VALUE_OF_MEANING };
LARGE_INTEGER n = { .QuadPart = SomeOtherVariable.QuadPart };
LARGE_INTEGER n = { .QuadPart = SomeStackParameter.QuadPart };

Counter example:

LARGE_INTEGER to = { .QuadPart = RELATIVE(MILLISECOND(5)) };
KeWait(&to);

/* C programmers reaction: Got it! */

On Sun, Jul 8, 2018 at 10:38 PM xxxxx@gmail.com
wrote:

> I believe anyone unable to find one single useful thing in c++ is dumb
> and/or obstinate. This is because c++ has a treasure chest of goods
> specifically for system level programming and more are being added all the
> time. It’s fantastic.
>
> Let’s take one. Today when we express relative time quantities in the
> kernel it is in negative 100 nanosecond units. So if we want a 10
> millisecond timeout the psuedo is like:
>
> LARGE_INTEGER n;
>
> n.QuadPart = -1000000; // programmers reaction: wtf is -100000?
>
> KeWait(n); // programmers reaction: wth didn’t you just pass -100000
> directly?
>
> c++ allows adding things like microsecond and millisecond tags on
> literals. So we can write this instead:
>
> KeWait(10ms); // programmers reaction: got it!
>
> So tell me which way do you prefer, c or c++? and if the former can you
> articulate why? I’ll try not to fall off my chair laughing.
>
>
>
> —
> 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>
>

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

Prokash_Sinha · July 8, 2018, 11:01pm

Of course, I would love to have C, nothing but C. Sorry just kidding :-). It pops up right there, which one to use. Did I use 2nd one, guess what?
Yes, but not on KeWait ( it was posix platform ). Also need to consider who is/are used to the old style, that it does not make sense to change.

The thing is when I want to marry someone, I want to marry the person ( i.e. financial safety ) as opposed marry the whole package family

That is the topic here. You know, I would love to write exception safe code, and would not demand for give me the assurance that in case of an exception ( kernel does not get lost ) — we talked about it at our last WAR STORY !

One other thing is to Parse thru all the necessary features, that can be applicable to kernel programming. In the document, that I referred earlier mentioned about never using singleton, and that is exactly I’ve seen in more than one File Filter.

Again, I’ve seen OSR article about how to create new(), delete() so I will have happy life allocating / freeing knowing that my some auxiliary routine would not foul up randomly …. Alternatively there is explicit/direct API to use in C, and it would nag me like my beloved one :-).

My personal choice is to wait for a canonical set that can be used explicitly. I don’t like hiding stuff when in kernel mode, so I spend as less time as possible in kernel debugging.

An example I gave, earlier, the silly example uses ifstream to have function scope, and allow some one to have multiple return point. Most any kernel guys either uses goto ( forward) to soft of FINALIZE section, or as I said do while stuff, and get to FINALIZE point. —- If I allow that example, then dynamic memory allocation has be to based on some vector with function scope. It is not much intuitive to me, sorry …

-Pro

On Jul 8, 2018, at 7:37 PM, xxxxx@gmail.com wrote:
>
> I believe anyone unable to find one single useful thing in c++ is dumb and/or obstinate. This is because c++ has a treasure chest of goods specifically for system level programming and more are being added all the time. It’s fantastic.
>
> Let’s take one. Today when we express relative time quantities in the kernel it is in negative 100 nanosecond units. So if we want a 10 millisecond timeout the psuedo is like:
>
> LARGE_INTEGER n;
>
> n.QuadPart = -1000000; // programmers reaction: wtf is -100000?
>
> KeWait(n); // programmers reaction: wth didn’t you just pass -100000 directly?
>
> c++ allows adding things like microsecond and millisecond tags on literals. So we can write this instead:
>
> KeWait(10ms); // programmers reaction: got it!
>
> So tell me which way do you prefer, c or c++? and if the former can you articulate why? I’ll try not to fall off my chair laughing.
>
>
>
> —
> 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:>

Jamey_Kirby · July 8, 2018, 11:06pm

>> My personal choice is to wait for a canonical set that can be used
explicitly. I don’t like hiding stuff when in kernel mode, so I spend as
less time as possible in kernel debugging.

Amen brother!

On Sun, Jul 8, 2018 at 11:01 PM xxxxx@gmail.com
wrote:

> Of course, I would love to have C, nothing but C. Sorry just kidding :-).
> It pops up right there, which one to use. Did I use 2nd one, guess what?
> Yes, but not on KeWait ( it was posix platform ). Also need to consider
> who is/are used to the old style, that it does not make sense to change.
>
> The thing is when I want to marry someone, I want to marry the person (
> i.e. financial safety ) as opposed marry the whole package family
>
> That is the topic here. You know, I would love to write exception safe
> code, and would not demand for give me the assurance that in case of an
> exception ( kernel does not get lost ) — we talked about it at our last WAR
> STORY !
>
> One other thing is to Parse thru all the necessary features, that can be
> applicable to kernel programming. In the document, that I referred earlier
> mentioned about never using singleton, and that is exactly I’ve seen in
> more than one File Filter.
>
> Again, I’ve seen OSR article about how to create new(), delete() so I will
> have happy life allocating / freeing knowing that my some auxiliary routine
> would not foul up randomly …. Alternatively there is explicit/direct API to
> use in C, and it would nag me like my beloved one :-).
>
> My personal choice is to wait for a canonical set that can be used
> explicitly. I don’t like hiding stuff when in kernel mode, so I spend as
> less time as possible in kernel debugging.
>
> An example I gave, earlier, the silly example uses ifstream to have
> function scope, and allow some one to have multiple return point. Most any
> kernel guys either uses goto ( forward) to soft of FINALIZE section, or as
> I said do while stuff, and get to FINALIZE point. —- If I allow that
> example, then dynamic memory allocation has be to based on some vector with
> function scope. It is not much intuitive to me, sorry …
>
> -Pro
>
> > On Jul 8, 2018, at 7:37 PM, xxxxx@gmail.com
> wrote:
> >
> > I believe anyone unable to find one single useful thing in c++ is dumb
> and/or obstinate. This is because c++ has a treasure chest of goods
> specifically for system level programming and more are being added all the
> time. It’s fantastic.
> >
> > Let’s take one. Today when we express relative time quantities in the
> kernel it is in negative 100 nanosecond units. So if we want a 10
> millisecond timeout the psuedo is like:
> >
> > LARGE_INTEGER n;
> >
> > n.QuadPart = -1000000; // programmers reaction: wtf is -100000?
> >
> > KeWait(n); // programmers reaction: wth didn’t you just pass -100000
> directly?
> >
> > c++ allows adding things like microsecond and millisecond tags on
> literals. So we can write this instead:
> >
> > KeWait(10ms); // programmers reaction: got it!
> >
> > So tell me which way do you prefer, c or c++? and if the former can you
> articulate why? I’ll try not to fall off my chair laughing.
> >
> >
> >
> > —
> > 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>
>
>
> —
> 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>
>

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