>On the contrary, operator overloading is fantastic in the kernel and
Microsoft has even gone to the trouble of defining some operators for us.
Here is an example. I am eager to to hear how this is evil >and the C way is
superior:
So you’re saying that MSFT encourages use of operator overloading the kernel
in the GENERAL case, because you found this one (somewhere), which I would
agree is indeed very natural?
That’s pretty absurd argument, imo.
// in C we are forced to scour the docs looking for this ridiculous
function
if (IsEqualGUID(&a, &b))
That really is on outrage. I hope that they find that IsEqualGUID bastard
and string him up by the balls.
Save for the C++ hecklers, I am pretty sure everyone else is capable of
picking out DATA() init syntax very naturally. That’s grade school type
stuff you could play “which one of these things is not >like the other” on
sesame street with. It’s just not that hard.
Yeah, I wasn’t really arguing that anyone would be incapable of appending
‘()’ to their new calls. Rather, that if you weren’t especially familiar
with C++, you wouldn’t know to do so, and errors caused by failing to do so
would be hard to find.
X y = new X;
v.
X y = new X();
They look kind of similar, no? And they both compile, without warning.
That’s grade school type stuff you could play “which one of these things is
not like the other” on sesame street with.
How very coy.
?Geesh, I guarantee you if DATA x={}; syntax was a C++ construct to zero
data rather than C then a number of people would be complaining about how
bad and evil it
For the record, I use C++ in a pretty full sense extensively in the kernel.
I just don’t necessarily advocate it as ‘better’ for any given situation,
and I definitely am not on some forced march of Evangelism.
It is quite clear to me that DATA() initialization is one of those cases
where C++ is more suitable than C for writing kernel code.
Yes, I get that. And as I said before, that’s great for you. But maybe not
for everybody else. Or maybe it is. I guess I’m just content to let them
choose for themselves. I’m not sure how you can argue that C++ is more
suitable for writing WINDOWS KERNEL MODE DRIVERS WITH THE WDK. I mean, it’s
unsupported. And you have to provide your own implementation. That’s just
how it is. There’s also this issue of all the kernels out there that people
have SOMEHOW managed to write in ‘C.’ Or Assembler. Or PL/I. In my
opinion, if you look at the history of truly massive software failures, one
of things that they all have in common is that they used a new language/tool
(commonly that was written for that specific project) that few of the
developers had experience with, because ‘it couldn’t be done in else>,’ where was frequently ‘C,’ and the new language was
frequently some 4GL that sucked. Always a bullshit argument. In
particular, several of the first large scale C++ projects outside of Bell
Labs were spectacular failures (see Mentor Graphics), simply because the
authors weren’t familiar with C++ yet bought into the idea that somehow
things would be ‘better’ just by using it. Almost anything produced using
tools with which you are less familiar is going to suffer the learning
curve. Arguing that using C++ for a WINDOWS KERNEL DRIVER is inherently
‘better’ or more ‘suitable’ makes no sense to me, that I use it frequently
and that it can be used just as well, notwithstanding.
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Friday, May 20, 2011 4:09 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] C++ support lib for kernel?
> the Kernel is not the place to leverage the more subtle features of c++ -
like, say, operator overloading
On the contrary, operator overloading is fantastic in the kernel and
Microsoft has even gone to the trouble of defining some operators for us.
Here is an example. I am eager to to hear how this is evil and the C way is
superior:
GUID a, b;
// in C we are forced to scour the docs looking for this ridiculous function
if (IsEqualGUID(&a, &b))
// in C++ it just happens naturally; a round of applause for operator ==
if (a == b)
> write your own. No ambiguity. No surprises. Does just what you want
No ambiguity? No surprises? Could not be further from the truth and it is
pretty astonishing to see someone advocate new or delete should do what you
want. So why aren’t we all overriding ExAllocatePool with our own version
that zeros every single allocation out too? And then when Microsoft decides
to include a basic new & delete in the next ntddk.h what are we to do with
our special version, comment out Microsoft’s I guess? Also keep in mind
there is more of a need now to base off or even share source code between
apps, drivers, and other operating systems. Really there are countless
reasons that writing your code to try to elevate undefined behavior to
defined behavior and rely on it could be a time bomb that will cause a
substantial architectural failure on something down the line.
Save for the C++ hecklers, I am pretty sure everyone else is capable of
picking out DATA() init syntax very naturally. That’s grade school type
stuff you could play “which one of these things is not like the other” on
sesame street with. It’s just not that hard. And it absolutely cannot
accidentally zero out the wrong area nor the wrong length which
RtlZeroMemory can, has, and will continue to do from time to time because it
on the other hand absolutely does lend itself to being used incorrectly.
Geesh, I guarantee you if DATA x={}; syntax was a C++ construct to zero data
rather than C then a number of people would be complaining about how bad and
evil it. It is quite clear to me that DATA() initialization is one of those
cases where C++ is more suitable than C for writing kernel code.
—
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
