Why do you all consider importing C++ code to FreeBSD kernel to be so
complicated at the beginning?
Matthias Andree wrote:
(please don't Cc me on list replies; chopping down the Cc list)
On Tue, 11 Jul 2006, [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.
But what's the point of C++ if it is mutilated below minimum standard
compliance levels so that you can no longer call it C++?
This discussion has been through for other systems such as Linux long
ago, and it wasn't lack of manpower, but lack of technical feasibility,
or in other words, what was still useful for a kernel wasn't that much
different from C any more. C99 already adressed several concerns of C89,
and ISTR that FreeBSD kernels are C99 code these days.
We can judge whether a C++ feature can or cannot be imported into FreeBSD
kernel by assemble code generated by GNU CC.
Great, make the whole kernel depend on compiler internals.
Can you imagine a single vendor who'd have interest in hauling so many
dependencies into their software and handle all the support? I can't.
Please complain about the portability of runtime library after reading
codes in /usr/src/contrib/libstdc++/libsupc++/.
Are they really so difficult to port?
Write a C stub and put the rest into userspace where C++ works.
For example, I think C++ exception handling is really poorly suited for
low-level code.
Which chops off one of C++'s legs to stand on.
Aside from the complexity of implementing C++ exception, in kernel, every
exception must be carefully processed. A simple exception throw may lay
memory leak and unfreed resource allocation. And outer exception catch
is difficult to help inner exception.
Well, you can LOOK DOWN UPON me, but I believe you cannot throw doubt on
FreeBSD's actuality: so weak USB support (kernel crash easier than many
other OSs that we laughed at and that we are laughing at), so weak PCI
device support.
Talking of USB, have you ever used a USB 2.0 Hi-Speed hub (single TT)
with Linux and plugged TWO devices into it and see Linux fail to talk to
the device you plugged in later? No? If so, you have zero clue how bad
USB support can get. And that's not the only problem Linux USB has had
or still has.
Actually, what I would talk about is Microsoft Windows 2000/XP. We should
ignore Microsoft's superiority just because we love FreeBSD.
Please look at files in /sys/pci/ and /sys/dev/*/. Why do so many PCI
device drivers repeat:
pci_read_config( ... )
...
sc->vr_res = bus_alloc_resource_any( ... );
...
sc->vr_irq = bus_alloc_resource_any( ... );
...
Is this kind of awful writing just of FreeBSD's style?
In contrast, with C++, we can avoid many code repeating among device
drivers.
How would C++ avoid such? Generic programming, RTTI support and such
stuff requires an awful lot of compile-time code generation and runtime
library support.
Why would people write Windows application with rather MFC/ATL/.NET
Framework than direct Windows API?
Why is gtkmm created for GTK+?
Would you write a X11 application with original X11 API, without QT or
other X11 toolkits?
Good packages for various APIs are much easier to learn/debug than those
original APIs.
If we would have constructed an object model in C++, a programmer who
master Microsoft MFC, Darwin I/O Kit could easily write a device drive
with the device's hardware data sheet.
And errata, and talking to the device happens in C-like programming
anyways...
--
Matthias Andree
------------------------------------------------------------------------
From Beijing, China
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
