-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Thursday, November 01, 2001 10:35 AM
To: NT Developers Interest List
Subject: [ntdev] Re: 3-rd party…
DANGER DANGER Will Robinson!!!
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of Dave Harvey
Sent: Wednesday, October 31, 2001 10:29 PM
To: NT Developers Interest List
Subject: [ntdev] Re: 3-rd party…
Max, we shouldn’t let the “less sophisticated” programmer write SMP code in
kernel mode. Its much easier to train someone on
C++ then to have them actually comprehend multi-processors. And I’ve
C++ certainly seen ample
proof the those with “metaphysical scholastic like” training can royally
screw up in C.
Since you can get most drivers write in C to compile with typically a few
changes if you rename file.c to file.cpp, C++ in the kernel does not need to
be a major change. In fact, doing the former happens to make the browser in
Visual Studio find references to field names, without affecting the binaries
generated.
So its difficult to argue that using the C++ compiler to compile C programs
in kernel mode is bad, since the only significant difference is that the
browser works better.
So:
ALL OF THE DRIVERS YOU WRITE ARE WRITTEN IN A SUBSET OF C++.
And:
SINCE your drivers are written in a subset of C++, have you picked a
reasonable subset?
One way to tell how committed you are to C only in the kernel is to consider
your own view of LARGE_INTEGER vs. ULONGLONG.
If you are a true “C only” believer, and you have a problem where you need
to keep stats on events that happen say 1,000,000 times per second, and you
conclude that you need a 64 bit bucket, do you declare it a “LARGE_INTEGER”
and use the old obscure macro to add to it, or do you declare it as
ULONGLONG, and use the + operator, allowing the compiler to issue the
multiple instructions to complete the add on a 32 bit machine (or cheat and
use LARGE_INTEGER::QuadPart)?
If you use “ULONGLONG”, you’re a “little pregnant”. You’ve accepted the
fact that you’d rather write code that’s easier to write and read, even if
you don’t completely know the machine language cost. As a compentent kernel
coder, you know that assigning to a ULONGLONG is not atomic (at least on a
32 bit CPU) and that adding ULONGLONGs takes more instructions than adding a
ULONG.
So now say that you have a struct:
struct stats {
ULONGLONG reads;
ULONGLONG writes;
…
};
and variables
struct stats a,b,c;
Wouldn’t you like to be able to write, which is not obscure at all, and, as
you did with ULONGLONG, even though you know this is more expensive than a
scaler subtraction
a = b - c;
rather than
StatsSub(a, b, c);
especially if the compiler can inline the former for you?
In summary:
Using C++ in the kernel does not require buying in to the fundamentalist OO
religion. Nor does it require you to use some package that wraps the IRPs in
some new thing so that you add another layer of code that arguably adds no
value.
-DH
----- Original Message -----
From: “Maxim S. Shatskih”
To: “NT Developers Interest List”
Sent: Wednesday, October 31, 2001 12:25 PM
Subject: [ntdev] Re: 3-rd party…
> Message>good programmer. On the contrary, putting C++ in the hands of
> Message>a less sophisticated
> >programmer is asking for trouble.
>
> Yes, especially of the “programmer” has small practical experience,
> but large experience in reading metaphysical scholastic
like
> Grady Booch.
>
> Give him C++ and you will have terrifying over-design, both in
> complexity and development time point of view. He would be the
kind
> of person who values following the abstract paradigm more then
> real-world performance, reliability or code readability.
>
> Max
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@syssoftsol.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com