> I will not be surprised if KMDF (very, very similar to IOKit) is developed using
the same kind of C++ internally.
Yes, the KMDF seems to be internally developed using not only the C but with using of the stuff that can be described as “MS approved ‘C with classes’ kernel subset” -) .
And no, IOKit and KMDF are very different in the imlemetation and the interface. KMDF exposes the raw C interface to the client. IOKit exposes the C++ class library - to do something useful one almost always subclasses whatever corresponding from the IOKit and implements the necessary virtual functions. Further the IOKit is implemented as the object-oriented class library whereas the KMDF is believed to be a pile of plane structures-wrappers around the kernel-exposed data types and C-functions. But the result is exactly the same - one just writes his drivers using these toolkits -)
Also, Apple’s CF reminds me on some pre-STL C++ contrainer objects, like the
MFC’s one.
Core Foundation, as far as i remember, is a user-land bridge between C- and ObjC-libraries. It’s not in the kernel, ObjC for driver development had been replaced by eC++ when NextStep became MacosX.
IOKit is based on the ‘libkern-c++’ - this is a kernel library for ‘basic object’, collections and strings. But yes - very similar in nature to the CF.
Also note: C++ standard RTTI is pathetic kludge, and thus is usually replaced
with better hand-made stuff, like DECLARE_DYNAMIC in MFC or OSDynamicCast in
IOKit.
It looks you are excessively strict about RTTI. The RTTI on my opinion is just a low level crutch exposed by statically-typed language for some run-time limited purposes and it does it’s duties well enough.
As well let’s just recall that when OSDynamicCast appeared the C++ was being in a slightly chaotic state. Moreover OSDynamicCast provides not just the RTTI in the C++ terms but also it exposes some kind of reflection.