On Tue, Jul 11, 2006 at 10:45:52PM +0800, [EMAIL PROTECTED] wrote: > Just as you said, C++ is more complicated than C. However, without > C++ exception and other advanced features, it hasn't brought much > complexity to C++ runtime library. Early C++ compiler even translates > C++ code into C code before real compilation.
RTTI, allocation, exceptions and static allocators all add complexity for the runtime library. If you really want to use C++ for a kernel, you must likely want to use all of them as well. > For example, I think C++ exception handling is really poorly suited for > low-level code. Bullshit. With a proper implementation exceptions add no overhead as long an exception is not thrown in terms of speed. It does matter somewhat in terms of code (or better: data) size, but the very same information is useful to generate much better tracebacks as well. RTTI is highly useful for debugging and semi-optional consistent checks, which should not be neglected either. I don't care about the abuse of explicitly comparing object types etc., but the ability to decide what exactly a certain object is. > But the "object model" is still obscure to understand no matter how many > people all over the world master C++. What's more, can the "object model" > function really as OpenDarwin's IOKit class model? > (http://developer.apple.com/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/HelperClassesChart/chapter_12_section_1.html) The kobj implementation has the same feature set as a lightweight C++, e.g. inheritance and virtual functions. That's basically what IOKit is using as well. It is not obscure, just a Domain Specific Language. > Now, OpenDarwin has owned a C++-based kernel object model. But why > cannot FreeBSD? Because the kernel is C and not many points to incrementally add C++ have been made, which makes it a worthwhile goal. And if you want to complain about redundancy in drivers, carefully look for differences which often far outweight the common functionality. Joerg _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"