On 08/20/10 09:48 AM, Nicolas Williams wrote:
On Fri, Aug 20, 2010 at 09:38:51AM +1200, Ian Collins wrote:
On 08/20/10 09:33 AM, Nicolas Williams wrote:
Any driver C++ code would still need a C++ run-time. Either you must
statically link it in, or you'll have a problem with multiple drivers
using different C++ run-times. If you statically link in the run-time,
then you're bloating the text of the kernel. If you're not then you
have a problem. C++ is bad because of its ABI issues, really.
You snipped the bit where I said
"Drivers and kernel modules are a good example; in that world you
have to live without the runtime library (which is dynamic only).
So you are effectively just using C++ as a superset of C with all
the benefits that offers."
So you basically loose the C++ specific parts of the standard
library and exceptions. But you still have the built in features of
the language.
I'm not sure it's that easy to avoid the C++ run-time when you're
coding.
Like anything else in software development, set guidelines and follow
them. The system is the ultimate arbitrator; you soon learn when you
module refuses to load!
And anyways, the temptation to build classes that can be used
elsewhere becomes rather strong. IMO C++ in the kernel is asking for
trouble. And C++ in user-land? Same thing: you'll end up wanting to
turn parts of your application into libraries, and then some other
developer will want to use those in their C++ app, and then you run into
the ABI issues all over again.
There are a couple of simple solutions to that. Either make library
code header only (which is most common for template based code) or
provide CC and gcc libraries, just like we have 32 and 64 bit versions
of other system libraries. Or just stick to one compiler, like Solaris
did before the big gcc build project kicked off.
--
Ian.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
