>>There is one more delegation of function call because kernel API is C
>API. But this is not so
>bad, you could even use __fastcall in your C++ define of the member
>function. the “this” and
For what? What advantages are achieved by this extra call?
This is like MFC’s CDC. Never used it in MFC apps, used the HDC
instead. Unnecessary wrapper.
MFC CDC is not a good example. That part of MFC, I believe, was resulted
from the early version of MS C++ compiler that did not have adequate C++
support and someone inside MFC group just learning C++ while writting that
piece of craps. And that craps is kept as it is because of the compatibility
issues.
if you use __forceinline in the suitable cases, there is no such extra call
as it is inline. It a gives cleaner code.
In many other cases, C program will have additional procedure call anyway to
increase the code readability. such as IRP_MJ_XXX/IPR_MN_YYY. In such cases,
C++ does not add additional function call overhead.
One dame thing about the kernel object is the first two data members Type,
Size
struct XXXObject
{
CSHORT Type;
CSHORT Size;
…
};
Had it been
struct XXXObject
{
#if defined(_WIN64) || defined(ANY64BITCPU)
LONGLONG Reserved;
#else
LONG Reserved;
#endif
CSHORT Type;
CSHORT Size;
…
};
It would have been entirely possible to write a C++ wrapper without the
extra delegation of function call and without using inline.
>place or two. It makes your code cleaner since you simply access your
>data members in your
>class “this-and-that” (implicitly this->this_and_that).
Cleaner code is the code where everything is explicitly qualified, so,
I prefer MyObj->Field.
Most people, include me, use m_Field to indicate that this is a data member
of the class.
>Another example is C++ template library wrapping of
>list/map/queue/tree is easier and
>cleaner than using C API and CONTAINING_RECORD macro while it incurs
>no overhead
>and code size penalty compared to C because its inline nature.
I see no difference.
type safe and it is done once and use as many type of data as one likes.
This cannot be said to a C program. How many times you have to type
CONTAINING_RECORD in your drivers if you uses list/map/queue/tree?
>Using a C++ library saves you a lot of typing,
>copy-paste-modify-rename.
At the expense of much, much lesser code readability.
You cannot apply this to every programmer.
>It is more robust code reuse.
>Absolutely not so, since the code becomes nearly unreadable.
>Code reuse of C code on copy/paste basis or on .C/.H module basis is
>much more a reality.
I actually prefer to make C++ class library the COM way, meaning it is
essentially a black box. This is called encapsulation.
>Look at Microsoft class, port, miniclass, miniport driver model, etc.
>I wished it could be in a
>class library form.
For what? To tie the OS to pecularities of the particular compiler and
to introduce the extra layer of undocumented innerworkings (how VMT is
placed etc)?
Isn’t C compiler a compiler?. Which popular C compiler now-a-day is not both
C/C++ compiler? we are talking about NT kernel, are we? Even in embedded
case, most popular embedded OSes supports C++ (gcc which, in most cases is
just g++).
Why there has to be an extra layer of undocumented innerworkings? What I
mean Had kernel API exposed C++ interface in addtional to pure C interface,
one does not have to fill all these function tables.
>Look at DMA adapator object API, does that not look like a C++
>object?
Exactly, or UNIX’s vnode is another example. This means - you can do
polymorphism without a language with hidden semantics. So why
introduce it?
The amount of typing necessary to define the vnode’s methods or the
C++ class is nearly the same.
One can do almost anything in C++ in C, just ugly and not type safe. Take a
look at C implementation of COM. Take a look C implemenation of C++
exception handling.
>Things like MDL etc.
Microsoft said one should treat many objects like MDL as opaque, or like IRP
as partically opaque. Isn’t C++ is better way to enforce such rules?
>In my C++ library, I don’t have many layers of inheritance, most no
That’s good. Deep inheritance trees are very, very rarely useful (UI
components is nearly the only place) while their drawbacks in code
readability are obvious.
Let’s put compiler issue aside. Assume C++ had the Java ability of
super.method() and assume kerenl interface had C++, would the layer drivers
model become much easier and more efficient since one did not have to
reparse the parameters in each and every layer and delegate the call to next
driver below.
>and faster than NT. If the kernel API is in C++
Also - it is good that C++ is not “pure OOP”, since the “pure OOP”
idea if flawed by definition. These languages are just plain slow.
There are good things in OOP - encapsulation and polymorphysm.
Inheritance is more often an evil, and abstract datatypes (operator +)
are just evil in terms of code readability.
But the good things of OOP are achievable in C, without a language
with hidden semantics.
Note COM. This technology is the exact subset of C++ features worth
using. No wonder MS ported it to kernel for KS/PortCls stack.
COM/C++ combo is in some sense to force C++ into a more pure OOP. It tries
to make reading other people’s code unnecessary if the interface is spec-ed
properly.
IMHO C++ is more suitable for inherently OO (like a virtual
world-style game with items and NPCs, or like a CAD) tasks, for UI
tasks and as a “smarter kind of Visual Basic” for whole lot of
nearly-VB-suitable tasks like writing email servers, document
management etc. System-level development is not such.
So, if use C++ in the kernel, one must define a narrow subset of
“features worth using in terms of code readability” and then follow
this subset.
Agree.
I have seen people abusing C++ to such an appalling extent that they starts
from defining classes of compiler intrinsic data types with all the
operators such as +/-/=/==/!=/… and built a driver with sizes of several
hundreds of KB that a driver of a few KB will do and do much faster. It is
those guys (I suspect they come from application developer background) who
give C++ a bad name.
Bi
You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%