>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.
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.
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.
Using a C++ library saves you a lot of typing,
copy-paste-modify-rename.
At the expense of much, much lesser code readability.
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.
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)?
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.
Things like MDL etc.
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.
and faster than NT. If the kernel API is in C++
C++ syscalls??? To tie all apps to some compiler?
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.
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.
Max