Re:Re: C++ coding

NTDEV
1

Since this topic has wandered far afield, I finally changed the subject line.

Actually C++ code is fairly easy to read without a “class browser”. I do
it all the time. I refuse to use an editor as poorly done as the VS editor
(remember: editors are not a technology, they are a religion).

If you can avoid the Turing Tarpit of template coding, you can code far
faster than in C, and more productively, too. (Alan J. Perlis, one of the
founders of our field, defined the Turing Tarpit as that methodology, or
state of being, or context, in which All Things Are Possible, but Nothing
Is easy).

I’ve watched a couple projects dissapear down the rabbit hole of excess
metaprogramming. I do a little template programming from time to time,
but I was once an expert metaprogrammer (in the mid-1970s to the
mid-1980s, before C++ had been invented). But because of this, I know
what a time-sink it can be. As a creator of general-purpose libraries
for a large community of users, it has value (which is what I was doing)
but its payoff on small projects with small teams is somewhere between
problematic and negative.

A colleague of mine once was told (as part of his contract) that the
driver had to written in MFC. I commented that this was one of the most
incredibly stupid ideas I had heard in a long life of hearing stupid
ideas, and he should walk away from this project. Several months later,
he told me I had been right.

> There is the “Thinking in C++” book, but no “Thinking in C”, why?
> Because C
> is just not a language for thinking. It is good only for coding.

Yes, because in C you will code alone, and have your task done.

In C++, you must both think and code to have the task done, which means
that C++ is more complex and just plain lesser productive :slight_smile:

Why C++ is used is because some lesser experienced managers (who are
basing on books and not real-world experience) and the novice programmers
think it is a “silver bullet” to solve the SD tasks. And than they drown
to the situation where >50% of SD’s effort is to comprehend the mess of
mis-created classes, templates and such which they have created at
previous stages of the project.

Hey, you cannot even read the dirty C++ code without a special tool called
“class browser”. :slight_smile:

This complexity is for nothing actually, and gives you nothing.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

2

> A colleague of mine once was told (as part of his contract) that the driver had to written in MFC.

I commented that this was one of the most incredibly stupid ideas I had heard in a long life of hearing
stupid ideas, and he should walk away from this project. Several months later, he told me I had been right.

Just incredible - it took him several months(!!!) to realize something that should be plainly obvious to anyone who is more or less familiar with system-level development concepts under any OS. One does not really need to be a competent Windows driver writer in order to realize that a library that encapsulates Win32 API just cannot be used by the kernel driver.

I just wonder which particular MFC class his driver would derive from. Please note that it has nothing to do with C++ language per se…

Anton Bassov

3

The problem was that it was “do it our way, we’re the ones paying you”.
It didn’t take him several months to realize this was a mistake; it took
seversl months for his irritation to reach the theshold where it dominated
the income stream.

> A colleague of mine once was told (as part of his contract) that the
> driver had to written in MFC.
> I commented that this was one of the most incredibly stupid ideas I had
> heard in a long life of hearing
> stupid ideas, and he should walk away from this project. Several months
> later, he told me I had been right.

Just incredible - it took him several months(!!!) to realize something
that should be plainly obvious to anyone who is more or less familiar with
system-level development concepts under any OS. One does not really need
to be a competent Windows driver writer in order to realize that a
library that encapsulates Win32 API just cannot be used by the kernel
driver.

I just wonder which particular MFC class his driver would derive from.
Please note that it has nothing to do with C++ language per se…

Anton Bassov

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

BTW, Joe, where did you find this thread, in the first place - I cannot find a thread like “C++ coding” in the last 2-month. It looks like you worked really hard in order to find a can of worms that you can open - after all, anything related to C++ has historically had a reputation of being highly inflammatory on NTDEV, don’t you think.
What was the exact point???

Anton Bassov

5

The original title was “DMA latency”, which wandered off-topic (I did not
start the diversion, only responded to it) so I changed the subject line
so it made more sense.

Driver construction is engineering. Since C++ is, as of WIN8, officially
supported, I think a discussion of the proper use and improper abuse of an
engineering tool becomes more relevant. In the past, C++ was a sort-of
war between The True Believers and The Heathens (and it didn’t matter
which side you were on, it was Us against Them). But I think it would be
a total disaster if every C++ wannabe programmer read “Learn C++ While You
Sleep” and started to use variadic templates to write a driver (wait…the
Microsoft compiler doesn’t support variadic templates). Therefore, flames
or not, I think it is important to educate people in the proper
engineering use of this tool. Remember that a lot of newbie driver
writers come from C++ application programming, and it is important that
they understand that writing a C++ driver is not like dashing off some C++
app. As an educator, I think the issue can no longer be ignored or simply
swept away with something like “Real Device Driver Programmers write in
C”. Now that C++ is supported, drivers WILL be written in C++; the only
question is whether they are quality drivers produced at reasonable cost,
and are maintainable, or drivers that are crap, take far too long to
write, and are totally unmaintainable.

The flame wars are over, and reality has set in. It is our responsibility
to ensure that reality is enduable.
joe

BTW, Joe, where did you find this thread, in the first place - I cannot
find a thread like “C++ coding” in the last 2-month. It looks like you
worked really hard in order to find a can of worms that you can open -
after all, anything related to C++ has historically had a reputation of
being highly inflammatory on NTDEV, don’t you think.
What was the exact point???

Anton Bassov

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

6

"every C++ wannabe programmer read “Learn C++ While You Sleep”

It’s “Learn C++ While You Sleep(100000000)”

7

> Now that C++ is supported, drivers WILL be written in C++; the only
question is whether they are quality drivers produced at reasonable cost,
and are maintainable, or drivers that are crap, take far too long to
write, and are totally unmaintainable

We added c++ support because the community was using regardless of our guidelines. The idea is that we formalize the guidelines into the tools, thus eliminating some poorly chosen oaths. All of the issues you bring up with cost, maintainability, etc are there regardless of our official support or not

d

debt from my phone

From: xxxxx@flounder.com
Sent: 10/24/2011 8:19 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Re:Re: C++ coding

The original title was “DMA latency”, which wandered off-topic (I did not
start the diversion, only responded to it) so I changed the subject line
so it made more sense.

Driver construction is engineering. Since C++ is, as of WIN8, officially
supported, I think a discussion of the proper use and improper abuse of an
engineering tool becomes more relevant. In the past, C++ was a sort-of
war between The True Believers and The Heathens (and it didn’t matter
which side you were on, it was Us against Them). But I think it would be
a total disaster if every C++ wannabe programmer read “Learn C++ While You
Sleep” and started to use variadic templates to write a driver (wait…the
Microsoft compiler doesn’t support variadic templates). Therefore, flames
or not, I think it is important to educate people in the proper
engineering use of this tool. Remember that a lot of newbie driver
writers come from C++ application programming, and it is important that
they understand that writing a C++ driver is not like dashing off some C++
app. As an educator, I think the issue can no longer be ignored or simply
swept away with something like “Real Device Driver Programmers write in
C”. Now that C++ is supported, drivers WILL be written in C++; the only
question is whether they are quality drivers produced at reasonable cost,
and are maintainable, or drivers that are crap, take far too long to
write, and are totally unmaintainable.

The flame wars are over, and reality has set in. It is our responsibility
to ensure that reality is enduable.
joe

BTW, Joe, where did you find this thread, in the first place - I cannot
find a thread like “C++ coding” in the last 2-month. It looks like you
worked really hard in order to find a can of worms that you can open -
after all, anything related to C++ has historically had a reputation of
being highly inflammatory on NTDEV, don’t you think.
What was the exact point???

Anton Bassov

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

8

An outstanding decision, in my opinion.

The thing is, all we’re really talking about here is a switch that basically
says don’t put anything I didn’t write anywhere unexpected.

That it’s c++ is almost incidental.

As far as people just suddenly starting to write drivers in C++ now because
of a LINKER switch named ‘/kernel,’ if you included the word ‘try,’ perhaps,
but it’s still no more or less possible than before. If they try to do
anything outside of what they could do with C++ before this WDK in a driver,
they’re still not going to be able to get it to work unless they know what
they are doing, same as before.

What MSFT did, in my opinion, was make it safe to use the parts that you
previously could use potentially unsafely, possibly without even knowing it,
with the added bonus of not forcing those aware of the potential problems
into not paging anything.

In my opinion, they fixed a bug in a tool. Bug might be a little strong,
but having, for example, a destructor end up in a different section
depending on whether it’s virtual or not (under some conditions that are not
common, nor possible at all unless you specifically mark code as pageable)
is not a feature. That’s the kind of esoteric stuff that this change
addressed, as I understand it.

The word for this decision, in my opinion, is sensible, and it’s easily one
of the best and definitely most refreshing things the WDK team has done in
years, along with the Jumbo CHM (which unfortunately is no more (and not wdk
proper)), and of course the vs integration (not my thing, but I think an
OVERWHELMINGLY good decision for the community as a whole).

What I think is just great is that they actually spent money to do this.
Not to develop roadmaps, not to evangelize SDV one more time, not try to
legislate with a blunt little tool named Certification who should be allowed
to write drivers.

This had to be a tough sell internally, so, as much as anything, I see it as
a really positive sign.

And for that, I say thank you, WDK Team.

You give me hope.

mm

On Oct 24, 2011 9:49 PM, “Doron Holan” wrote:

> > Now that C++ is supported, drivers WILL be written in C++; the only
> question is whether they are quality drivers produced at reasonable cost,
> and are maintainable, or drivers that are crap, take far too long to
> write, and are totally unmaintainable
>
> We added c++ support because the community was using regardless of our
> guidelines. The idea is that we formalize the guidelines into the tools,
> thus eliminating some poorly chosen oaths. All of the issues you bring up
> with cost, maintainability, etc are there regardless of our official support
> or not
>
> d
>
> debt from my phone
> ------------------------------
> From: xxxxx@flounder.com
> Sent: 10/24/2011 8:19 PM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] Re:Re: C++ coding
>
> The original title was “DMA latency”, which wandered off-topic (I did not
> start the diversion, only responded to it) so I changed the subject line
> so it made more sense.
>
> Driver construction is engineering. Since C++ is, as of WIN8, officially
> supported, I think a discussion of the proper use and improper abuse of an
> engineering tool becomes more relevant. In the past, C++ was a sort-of
> war between The True Believers and The Heathens (and it didn’t matter
> which side you were on, it was Us against Them). But I think it would be
> a total disaster if every C++ wannabe programmer read “Learn C++ While You
> Sleep” and started to use variadic templates to write a driver (wait…the
> Microsoft compiler doesn’t support variadic templates). Therefore, flames
> or not, I think it is important to educate people in the proper
> engineering use of this tool. Remember that a lot of newbie driver
> writers come from C++ application programming, and it is important that
> they understand that writing a C++ driver is not like dashing off some C++
> app. As an educator, I think the issue can no longer be ignored or simply
> swept away with something like “Real Device Driver Programmers write in
> C”. Now that C++ is supported, drivers WILL be written in C++; the only
> question is whether they are quality drivers produced at reasonable cost,
> and are maintainable, or drivers that are crap, take far too long to
> write, and are totally unmaintainable.
>
> The flame wars are over, and reality has set in. It is our responsibility
> to ensure that reality is enduable.
> joe
>
> > BTW, Joe, where did you find this thread, in the first place - I cannot
> > find a thread like “C++ coding” in the last 2-month. It looks like you
> > worked really hard in order to find a can of worms that you can open -
> > after all, anything related to C++ has historically had a reputation of
> > being highly inflammatory on NTDEV, don’t you think.
> > What was the exact point???
> >
> > Anton Bassov
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

9

Glad the wdk team can be of service :slight_smile:

d

debt from my phone

From: Martin O’Brien
Sent: 10/24/2011 10:53 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Re:Re: C++ coding

An outstanding decision, in my opinion.

The thing is, all we’re really talking about here is a switch that basically says don’t put anything I didn’t write anywhere unexpected.

That it’s c++ is almost incidental.

As far as people just suddenly starting to write drivers in C++ now because of a LINKER switch named ‘/kernel,’ if you included the word ‘try,’ perhaps, but it’s still no more or less possible than before. If they try to do anything outside of what they could do with C++ before this WDK in a driver, they’re still not going to be able to get it to work unless they know what they are doing, same as before.

What MSFT did, in my opinion, was make it safe to use the parts that you previously could use potentially unsafely, possibly without even knowing it, with the added bonus of not forcing those aware of the potential problems into not paging anything.

In my opinion, they fixed a bug in a tool. Bug might be a little strong, but having, for example, a destructor end up in a different section depending on whether it’s virtual or not (under some conditions that are not common, nor possible at all unless you specifically mark code as pageable) is not a feature. That’s the kind of esoteric stuff that this change addressed, as I understand it.

The word for this decision, in my opinion, is sensible, and it’s easily one of the best and definitely most refreshing things the WDK team has done in years, along with the Jumbo CHM (which unfortunately is no more (and not wdk proper)), and of course the vs integration (not my thing, but I think an OVERWHELMINGLY good decision for the community as a whole).

What I think is just great is that they actually spent money to do this. Not to develop roadmaps, not to evangelize SDV one more time, not try to legislate with a blunt little tool named Certification who should be allowed to write drivers.

This had to be a tough sell internally, so, as much as anything, I see it as a really positive sign.

And for that, I say thank you, WDK Team.

You give me hope.

mm

On Oct 24, 2011 9:49 PM, “Doron Holan” > wrote:
> Now that C++ is supported, drivers WILL be written in C++; the only
question is whether they are quality drivers produced at reasonable cost,
and are maintainable, or drivers that are crap, take far too long to
write, and are totally unmaintainable

We added c++ support because the community was using regardless of our guidelines. The idea is that we formalize the guidelines into the tools, thus eliminating some poorly chosen oaths. All of the issues you bring up with cost, maintainability, etc are there regardless of our official support or not

d

debt from my phone
________________________________
From: xxxxx@flounder.commailto:xxxxx
Sent: 10/24/2011 8:19 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Re:Re: C++ coding

The original title was “DMA latency”, which wandered off-topic (I did not
start the diversion, only responded to it) so I changed the subject line
so it made more sense.

Driver construction is engineering. Since C++ is, as of WIN8, officially
supported, I think a discussion of the proper use and improper abuse of an
engineering tool becomes more relevant. In the past, C++ was a sort-of
war between The True Believers and The Heathens (and it didn’t matter
which side you were on, it was Us against Them). But I think it would be
a total disaster if every C++ wannabe programmer read “Learn C++ While You
Sleep” and started to use variadic templates to write a driver (wait…the
Microsoft compiler doesn’t support variadic templates). Therefore, flames
or not, I think it is important to educate people in the proper
engineering use of this tool. Remember that a lot of newbie driver
writers come from C++ application programming, and it is important that
they understand that writing a C++ driver is not like dashing off some C++
app. As an educator, I think the issue can no longer be ignored or simply
swept away with something like “Real Device Driver Programmers write in
C”. Now that C++ is supported, drivers WILL be written in C++; the only
question is whether they are quality drivers produced at reasonable cost,
and are maintainable, or drivers that are crap, take far too long to
write, and are totally unmaintainable.

The flame wars are over, and reality has set in. It is our responsibility
to ensure that reality is enduable.
joe

> BTW, Joe, where did you find this thread, in the first place - I cannot
> find a thread like “C++ coding” in the last 2-month. It looks like you
> worked really hard in order to find a can of worms that you can open -
> after all, anything related to C++ has historically had a reputation of
> being highly inflammatory on NTDEV, don’t you think.
> What was the exact point???
>
> Anton Bassov
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx>

10

I’ve known folks who have been writing C++ drivers for Windows for the last 20 years–all the way back to Windows 3 VxD’s if you can believe it and did a good job with it. Now I’ve never met anyone who is my equal in C. I’m on a totally different level than say the scribble source code in the DDK. No matter how good someone can write some C code, I could always write it better and colleagues throughout my career knew that. Never the less, I’ve been writing C++ drivers since 10 years and loving the increased productivity and elegant code. No matter how good I could write something in C, I can now elevate to an even higher level by writing it better in C++. Looking back over my career one regret is not switching sooner rather than taking a cautious approach earlier on.

I am all for giving driver developers the same basic freedoms as other developers are awarded. Official support of C++ is good for developers that are capable of using the language to their advantage like myself who might have otherwise hesitated. The beauty is if you don’t like C++, then you are welcome to use C. And if you look down at C++ as worse and laugh at it then don’t say I didn’t warn you when you are no longer competitive in the market place with those making C++ fly. And there are getting to be quite a few of those folks out there. Don’t let the voices of a few noisy, anti C++ people fool you.

11

>

We added c++ support because the community was using regardless of our
guidelines. The idea is that we formalize the guidelines into the
tools, thus
eliminating some poorly chosen oaths. All of the issues you bring up
with
cost, maintainability, etc are there regardless of our official
support or not

Ah yes, the “supervised drug injecting rooms” approach. We don’t want
you to inject drugs, but we know you are going to anyway so we’ll
provide a safe(r) environment in which you can do so.

James

12

The recognition of C++ is a reasonable one. I find C overly confining
after 15 years of C++ programming.

But, as a friend of mine observed, “You can write a bad FORTRAN program in
any language”. The official sanctioning of C++ will mean that a lot of
application programmers will start to use C++ in the kernel as if it is
C++ in user space, complete with exceptions, STL, etc. And
metaprogramming is a time sink that in the case of a single driver is
unlikely to pay off, while adding complexity (OTOH, someone writing a C++
library for driver writers should feel free to use it).

Drivers are a very different world from apps; while I regularly see apps
with > 100K SLOC, very few drivers (except graphics drivers) even approach
that. The concepts of robustness are quite different (although I tend to
try to get the same robustness in apps that I would in drivers, most
programmers are not that obsessive).

Hence, those who DO use C++ can now see the era of DADT is over, and
should free to share their expertise in the use of C++ in drivers without
fear of starting a flame war.
joe

(OK, full disclosure: I am an MVP in C++/MFC)

> Now that C++ is supported, drivers WILL be written in C++; the only
question is whether they are quality drivers produced at reasonable cost,
and are maintainable, or drivers that are crap, take far too long to
write, and are totally unmaintainable

We added c++ support because the community was using regardless of our
guidelines. The idea is that we formalize the guidelines into the tools,
thus eliminating some poorly chosen oaths. All of the issues you bring up
with cost, maintainability, etc are there regardless of our official
support or not

d

debt from my phone

From: xxxxx@flounder.com
Sent: 10/24/2011 8:19 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Re:Re: C++ coding

The original title was “DMA latency”, which wandered off-topic (I did not
start the diversion, only responded to it) so I changed the subject line
so it made more sense.

Driver construction is engineering. Since C++ is, as of WIN8, officially
supported, I think a discussion of the proper use and improper abuse of an
engineering tool becomes more relevant. In the past, C++ was a sort-of
war between The True Believers and The Heathens (and it didn’t matter
which side you were on, it was Us against Them). But I think it would be
a total disaster if every C++ wannabe programmer read “Learn C++ While You
Sleep” and started to use variadic templates to write a driver (wait…the
Microsoft compiler doesn’t support variadic templates). Therefore, flames
or not, I think it is important to educate people in the proper
engineering use of this tool. Remember that a lot of newbie driver
writers come from C++ application programming, and it is important that
they understand that writing a C++ driver is not like dashing off some C++
app. As an educator, I think the issue can no longer be ignored or simply
swept away with something like “Real Device Driver Programmers write in
C”. Now that C++ is supported, drivers WILL be written in C++; the only
question is whether they are quality drivers produced at reasonable cost,
and are maintainable, or drivers that are crap, take far too long to
write, and are totally unmaintainable.

The flame wars are over, and reality has set in. It is our responsibility
to ensure that reality is enduable.
joe

> BTW, Joe, where did you find this thread, in the first place - I cannot
> find a thread like “C++ coding” in the last 2-month. It looks like you
> worked really hard in order to find a can of worms that you can open -
> after all, anything related to C++ has historically had a reputation of
> being highly inflammatory on NTDEV, don’t you think.
> What was the exact point???
>
> Anton Bassov
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

13

It (WDK support for C++) had to be done, because people were using it (often dangerously because “they know better”) regardless of the constraints.

So, support for C++ in the WDK is a good thing for the community.

Unfortunately, the likely outcome will be more kernel-mode code written in C++ by people who don’t understand what they’re doing, leading to even larger, slower, and harder to maintain drivers.

Support of C++ couldn’t be avoided – but it’s not something I personally greet with enthusiasm. Aside from my personal hatred of the language, I’ve just seen waaaaay too many bad C++ programs (kernel-mode and otherwise) to be willing to jump on the C++ bandwagon.

Peter
OSR

14

That’s my point. C++ is a language that
(a) allows bad programmers to write REALLY bad code
(b) encourgages your “inner geek” to expend massive effort to do things
that don’t need to be done (hairy class structures, subtle overloading,
and metaprogramming)

Consequently, it requires a good deal more skill to be a good C++
programmer than a good C programmer, mostly in deciding what language
features to AVOID.

Even when I taught C, I would tell students “just because it CAN be done
in the language does not mean it is Best Practice to DO it”.

You can’t convince a C++ programmer that C is a good language just by
saying so. Nor can you convince a C programmer that C++ is a good
language just by saying so. The ultimate deciding factor is if you see an
elegantly-written C++ driver that is crystal-clear for maintenance, and
was written in half the time and with fewer bugs. Citing bad amateur code
does not indicate what an experienced programmer can do.

We already experienced this change in application space; I would not even
CONSIDER writing a GUI program using the raw WIN32 API; my choice is MFC.
Others like ‘qt’. Anything is better than the raw API. I could write a
whole essay on that topic.

To invert my friend’s characterization, “A good programmer could write a
device driver in FORTRAN” (and I apologize to those who will now have
nightmares for weeks from contemplating this).

There is nothing uglier than the sound of a paradigm shifting without a
clutch [adapted from a Dilbert cartoon]

Unfortunately, the likely outcome will be more kernel-mode code written in
C++ by people who don’t understand what they’re doing, leading to even
larger, slower, and harder to maintain drivers.

Peter
OSR

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

15

There must be an LSI-11 simulator running RT-11 somewhere we could test that theory …

:slight_smile:
Dave Cattley

16

I forgot to add this link: What would have happened if Theodore Seuss
Geisel had been an MFC programmer?

http://www.flounder.com/mcgrews_view.htm

If you are a C++ programmer, or have used MFC, it’s even funnier.

(those who know the original may also find it amusing to compare the two
versions. Hey, I had to do SOMETHING to avoid boredom on long plane
flights and evenings in motels)
joe

17

You don’t have to test the theory if you stretch a device driver to be a
program controlling a device. I did a number of these on PDP-11’s while
working my way through grad school. Also, wrote several system
utilities for our highly modified version of RT-11 in Fortran since that
compiler had decent string manipulation.

I never did it but I believe the extreme example is the Prime systems
which the OS was written in Fortran.

Personally, I am like Peter, if I use C++ at all in a driver in the
future it will be extremely limited. It is interesting that many years
ago Mark Roddy and I worked on a team that was contributing to the next
generation Unix, when Unix Systems Lab’s was still part of AT&T and
there was a lot of access to Bell Labs and the C++ guru’s there. The
design team looked a lot at the question of C++ in the kernel, and in
the end limited it extremely, mainly some simple classes to provide
types that were missing from C such as 64-bit integer support. Having
written enough drivers for Windows before 64-bit integer compiler
support I can fully endorse those concepts, but like the Unix team I
would limit beyond that.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Dave Cattley” wrote in message news:xxxxx@ntdev:

>


>
> There must be an LSI-11 simulator running RT-11 somewhere we could test that theory …
>
> :slight_smile:
> Dave Cattley

18

The recognition of C++ as supported for NT kernel programming is a
clear sign that it is as much of a dinosaur as a programming language
as C or assembly.

Mark Roddy

On Tue, Oct 25, 2011 at 9:32 AM, wrote:
> The recognition of C++ is a reasonable one. ?I find C overly confining
> after 15 years of C++ programming.
>
> But, as a friend of mine observed, “You can write a bad FORTRAN program in
> any language”. ?The official sanctioning of C++ will mean that a lot of
> application programmers will start to use C++ in the kernel as if it is
> C++ in user space, complete with exceptions, STL, etc. ?And
> metaprogramming is a time sink that in the case of a single driver is
> unlikely to pay off, while adding complexity (OTOH, someone writing a C++
> library for driver writers should feel free to use it).
>
> Drivers are a very different world from apps; while I regularly see apps
> with > 100K SLOC, very few drivers (except graphics drivers) even approach
> that. ?The concepts of robustness are quite different (although I tend to
> try to get the same robustness in apps that I would in drivers, most
> programmers are not that obsessive).
>
> Hence, those who DO use C++ can now see the era of DADT is over, and
> should free to share their expertise in the use of C++ in drivers without
> fear of starting a flame war.
> ? ? ? ?joe
>
> (OK, full disclosure: I am an MVP in C++/MFC)
>
>>> Now that C++ is supported, drivers WILL be written in C++; the only
>> question is whether they are quality drivers produced at reasonable cost,
>> and are maintainable, or drivers that are crap, take far too long to
>> write, and are totally unmaintainable
>>
>> We added c++ support because the community was using regardless of our
>> guidelines. The idea is that we formalize the guidelines into the tools,
>> thus eliminating some poorly chosen oaths. ?All of the issues you bring up
>> with cost, maintainability, etc are there regardless of our official
>> support or not
>>
>> d
>>
>> debt from my phone
>> ________________________________
>> From: xxxxx@flounder.com
>> Sent: 10/24/2011 8:19 PM
>> To: Windows System Software Devs Interest List
>> Subject: RE:[ntdev] Re:Re: C++ coding
>>
>> The original title was “DMA latency”, which wandered off-topic (I did not
>> start the diversion, only responded to it) so I changed the subject line
>> so it made more sense.
>>
>> Driver construction is engineering. ?Since C++ is, as of WIN8, officially
>> supported, I think a discussion of the proper use and improper abuse of an
>> engineering tool becomes more relevant. ?In the past, C++ was a sort-of
>> war between The True Believers and The Heathens (and it didn’t matter
>> which side you were on, it was Us against Them). ?But I think it would be
>> a total disaster if every C++ wannabe programmer read “Learn C++ While You
>> Sleep” and started to use variadic templates to write a driver (wait…the
>> Microsoft compiler doesn’t support variadic templates). ?Therefore, flames
>> or not, I think it is important to educate people in the proper
>> engineering use of this tool. ?Remember that a lot of newbie driver
>> writers come from C++ application programming, and it is important that
>> they understand that writing a C++ driver is not like dashing off some C++
>> app. ?As an educator, I think the issue can no longer be ignored or simply
>> swept away with something like “Real Device Driver Programmers write in
>> C”. ?Now that C++ is supported, drivers WILL be written in C++; the only
>> question is whether they are quality drivers produced at reasonable cost,
>> and are maintainable, or drivers that are crap, take far too long to
>> write, and are totally unmaintainable.
>>
>> The flame wars are over, and reality has set in. ?It is our responsibility
>> to ensure that reality is enduable.
>> ? ? ? ? ?joe
>>
>>> BTW, Joe, where did you find this thread, in the first place - I cannot
>>> find a thread like “C++ coding” in the last 2-month. It looks like you
>>> worked really hard in order to find a can of worms that you can open -
>>> after all, anything related to C++ has historically had a reputation of
>>> being highly inflammatory on NTDEV, don’t you think.
>>> What was the exact point???
>>>
>>> Anton Bassov
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

19

FORTRAN was bad enough, but did you HAVE to being up RT-11? I thought those memories were long gone, but NOOOOOOO, you had to refresh them!

Greg

— xxxxx@msn.com wrote:

From: Dave Cattley
To: “Windows System Software Devs Interest List”
Subject: RE: [ntdev] Re:Re: C++ coding
Date: Tue, 25 Oct 2011 11:09:09 -0400



There must be an LSI-11 simulator running RT-11 somewhere we could test that theory …

:slight_smile:
Dave Cattley
—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

20

LOL

mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Tuesday, October 25, 2011 8:19 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Re:Re: C++ coding

The recognition of C++ as supported for NT kernel programming is a clear
sign that it is as much of a dinosaur as a programming language as C or
assembly.

Mark Roddy

On Tue, Oct 25, 2011 at 9:32 AM, wrote:
> The recognition of C++ is a reasonable one. ?I find C overly confining
> after 15 years of C++ programming.
>
> But, as a friend of mine observed, “You can write a bad FORTRAN
> program in any language”. ?The official sanctioning of C++ will mean
> that a lot of application programmers will start to use C++ in the
> kernel as if it is
> C++ in user space, complete with exceptions, STL, etc. ?And
> metaprogramming is a time sink that in the case of a single driver is
> unlikely to pay off, while adding complexity (OTOH, someone writing a
> C++ library for driver writers should feel free to use it).
>
> Drivers are a very different world from apps; while I regularly see
> apps with > 100K SLOC, very few drivers (except graphics drivers) even
> approach that. ?The concepts of robustness are quite different
> (although I tend to try to get the same robustness in apps that I
> would in drivers, most programmers are not that obsessive).
>
> Hence, those who DO use C++ can now see the era of DADT is over, and
> should free to share their expertise in the use of C++ in drivers
> without fear of starting a flame war.
> ? ? ? ?joe
>
> (OK, full disclosure: I am an MVP in C++/MFC)
>
>>> Now that C++ is supported, drivers WILL be written in C++; the only
>> question is whether they are quality drivers produced at reasonable
>> cost, and are maintainable, or drivers that are crap, take far too
>> long to write, and are totally unmaintainable
>>
>> We added c++ support because the community was using regardless of
>> our guidelines. The idea is that we formalize the guidelines into the
>> tools, thus eliminating some poorly chosen oaths. ?All of the issues
>> you bring up with cost, maintainability, etc are there regardless of
>> our official support or not
>>
>> d
>>
>> debt from my phone
>> ________________________________
>> From: xxxxx@flounder.com
>> Sent: 10/24/2011 8:19 PM
>> To: Windows System Software Devs Interest List
>> Subject: RE:[ntdev] Re:Re: C++ coding
>>
>> The original title was “DMA latency”, which wandered off-topic (I did
>> not start the diversion, only responded to it) so I changed the
>> subject line so it made more sense.
>>
>> Driver construction is engineering. ?Since C++ is, as of WIN8,
>> officially supported, I think a discussion of the proper use and
>> improper abuse of an engineering tool becomes more relevant. ?In the
>> past, C++ was a sort-of war between The True Believers and The
>> Heathens (and it didn’t matter which side you were on, it was Us
>> against Them). ?But I think it would be a total disaster if every C++
>> wannabe programmer read “Learn C++ While You Sleep” and started to
>> use variadic templates to write a driver (wait…the Microsoft
>> compiler doesn’t support variadic templates). ?Therefore, flames or
>> not, I think it is important to educate people in the proper
>> engineering use of this tool. ?Remember that a lot of newbie driver
>> writers come from C++ application programming, and it is important
>> that they understand that writing a C++ driver is not like dashing
>> off some C++ app. ?As an educator, I think the issue can no longer be
>> ignored or simply swept away with something like “Real Device Driver
>> Programmers write in C”. ?Now that C++ is supported, drivers WILL be
>> written in C++; the only question is whether they are quality drivers
>> produced at reasonable cost, and are maintainable, or drivers that are
crap, take far too long to write, and are totally unmaintainable.
>>
>> The flame wars are over, and reality has set in. ?It is our
>> responsibility to ensure that reality is enduable.
>> ? ? ? ? ?joe
>>
>>> BTW, Joe, where did you find this thread, in the first place - I
>>> cannot find a thread like “C++ coding” in the last 2-month. It looks
>>> like you worked really hard in order to find a can of worms that you
>>> can open - after all, anything related to C++ has historically had a
>>> reputation of being highly inflammatory on NTDEV, don’t you think.
>>> What was the exact point???
>>>
>>> Anton Bassov
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer