> equivalent STL class available; are you going to do a priority queue by hand
just because it’s inside your driver and the DDK says you should write it in
C ? Somehow I don’t buy that logic!
Oh no. Hidden semantics. Lots of extra memory allocation (yes, OO programs are very stupid in terms of pool/heap use). Poor
uncommented STL source.
Some idiotic classes called “iterators” instead of RtlEnumeratexxx function (is it a class wrapper around the “RestartKey”
variable?)
Is all of this OK?
Sorry, I prefer good old InsertTailList and CONTAINING_RECORD to all this black magic and explicit function calls to any implicit
stuff which uses overloaded assignments and field accesses and templates.
What the computer really does is a function call. I prefer to see explicitly what the computer does and be not bothered with an
extra level of abstractions called “iterator class” or “virtual base class”.
This black magic can be OK to write something like ICQ. Not more. This is a trend to VB and Java side, to languages unacceptable for
system-level development.
Now let’s see:
class A
class B : public A
class C : public A
class D : public A
Then a developer who supports it sees a bug in B. The research have shown that the bug is inherited from A. The developer patches
A… and breaks C and D who were dependent of this A’s behavior!
A complete mess, I would say. Fixing bugs in such environment often leads to full rewrite (without inheritance). And this is real
even in average-complexity UI app (multi-mode text editor, for instance).
Anyway - supporting the code which uses inheritance have a trend of moving everything to the inheritance root. Even Stroustroup
noticed this.
The practice is on my side (yes, “appeal to authority” 
). MS practically never use C++ for system-level development. Neither
does the Linux team. No C++ in Linux kernel, and I’ve heard that this is because Linus personally is very much against it. Due to
the very same reasons.
You want polymorphism? OK, look at Linux VFS stack - this is polymorphism in C.
You want encapsulation? OK, “static” C keyword is for you.
You want inheritance? Wow… have you considered the question thoroughly?
In fact, just renaming a blah.c file into blah.cpp already makes sense, for
example, we can make polymorphism work for us by redefining OS entry points
without redundant parameters that do nothing but fill up lines of code.
For what? To add a layer of obscurity? I’m not so lazy in writing these parameters to, for instance, KeWaitForSingleObject. In the
worst case I will write a MyWait() macro to do this.
using ATL I don’t need to know about low level OS APIs.
Win32 APIs are fine without any idiotic wrappers like CDC or such. It is USER’s message handling which requires a help from MFC.
Anyway - windowed GUI is OO by the very idea, so, having an OO toolkit for it is very good. But wrapping sockets, HDCs and files in
clasess is just a stupidity. For what? Why CAsyncSocket is better then Berkeley API?
Now let’s speak on drivers. Having a KIrp class instead of struct _IRP just adds an obscure wrapper layer over the kernel-supported
IRP functions which have their own cans of worms.
(reverse-engineed pseudo-source of IoCompleteRequest path is usually the best reference on IRP handling the same is true on PnP
bus driver’s MJ_PNP path).
Your ATL sample is wrong, ATL is a toolkit to write OO COM classes and not more, it is not a wrapper around Win32 API.
And then, where does it stop ? Are you going to write directly to the OS, or
do you agree to use Winsock ? Are you going to write direct to the OS, or do
you agree to use OpenGL ?
It stops when hidden semantics and do-nothing wrappers being introduced. WinSock and OpenGL do not introduce it, while CAsyncSocket
does.
Even ADO is OK, it is a simple wrapper to over-complex OLE DB, while KIrp is not simpler then struct _IRP, it is more complex than
the C IRP structure.
I believe that the onion peel principle applies
fully here: the higher level we can afford to operate, the easier it is to
write code and get it working.
…and to get it working and performing poorly due to idiotic heap management done by “strict OO” code. Ever heard of great
performance of Java?
…and to get it nearly un-maintainable due to hidden semantics.
…and so on.
Yes, easier to write something more or less alive to report to your boss. Harder to maintain in the future, especially in team.
Harder to solve performance problems. Harder to write something non-trivial when the out-of-the-box classes will not help.
Yes, this is OK for things like e-shops using ASP and ADO (using #import <msado20.dll> is the simplest way of database programming
in MS C++), but not for system-level stuff.
Max
—
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</msado20.dll>