Joerg Sonnenberger wrote:
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.
Aside from the complexity of C++ exception support, in FreeBSD
kernel, every exception must be carefully processed, simple
exception throw and catch may lay memory leak and resource non-freeing
inside kernel if the programmer fails to pay enough attention.
Even if C++ code is carefully written for FreeBSD kernel, outer
exception catch is so difficult to help deep inner exception.
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.
A domain specific language, C function pointer list, software
context and other independent kernel functions are obscure enough for
FreeBSD newbies.
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.
If there's only small differences, there operations can be packed
into a function tunable by some arguments.
Joerg
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
------------------------------------------------------------------------
From Beijing, China
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
