Date: Wed, 12 Jul 2006 01:40:01 +0800 From: mag@intron.ac To: Joerg Sonnenberger <joerg@britannica.bec.de> Cc: freebsd-hackers@freebsd.org Subject: Re: kern/99979: Get Ready for Kernel Module in C++ Message-ID: <1152639658.28572@origin.intron.ac> In-Reply-To: <20060711152231.GB1487@britannica.bec.de> References: <84dead720607092015q7f1701abse143f3855c2aa95a@mail.gmail.com> <1152540567.99616@origin.intron.ac> <44B2AE69.4080703@elischer.org> <44B2D2DF.2000401@sh.cvut.cz> <86sll8zl9x.fsf@xps.des.no> <courier.44B35DBC.00003F75@intron.ac> <86fyh8zgw8.fsf@xps.des.no> <courier.44B37714.00004B4D@intron.ac> <868xn0z8w9.fsf@xps.des.no> <1152629241.24779@origin.intron.ac> <20060711152231.GB1487@britannica.bec.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Joerg Sonnenberger wrote:
> On Tue, Jul 11, 2006 at 10:45:52PM +0800, mag@intron.ac 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 "freebsd-hackers-unsubscribe@freebsd.org"
------------------------------------------------------------------------
From Beijing, China
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1152639658.28572>