"Systems programming" (was: Language Niches (long))

[Brendan Hahn]

grante at visi.com (Grant Edwards) wrote:
>As long we're completely off-topic (Python-wise)...
 [...]
>The question of how to write a Linux driver in C++ comes up
>fairly regularly.  In theory it's possible as long as you don't
>use features X,Y, and Z, and you include a set of kenel-mode runtime
>support routines.  Nobody ever wants to try it badly enough.

Exactly -- it's all about the runtime support, and kernel-space C++ runtime
implementations are all over the map in terms of features and performance. 
Microsoft has a pretty good one for NT, but the *n*x world will drive you
crazy.

There's actually a spec for "Embedded C++", a stripped-down version of the
language (no templates, exceptions, or RTTI, I think some inheritance
limitations and a few other things) intended for embedded systems and other
environments where you just don't want to deal with the whole ball of wax.

>>You could use Objective-C on the old NeXT systems -- Apple has
>>switched to a C++ IO system, for better performance, but using
>>a restricted subset of the language.  Haven't tried it yet but
>>I think it'll be nice.
>
>Is that in OS X?  I thought it was BSD under the hood?

It's a Mach-based system. In a real Mach system you have the Mach kernel
and one or more "personalities" layered above it providing your typical
"OS" services.  For MacOS X Apple has created a sort of hybrid with the
kernel and personality layers much more tightly coupled, and the
personality is BSD.

The IO subsystem ("IOKit") for MacOS X is largely inherited from NeXT,
though, and is not at all like the IO environment for a typical BSD system. 
It's a whole O-O hierarchy modelling interfaces, devices, drivers,
etc...Apple has redone it based on C++ rather than Objective-C to cut out
the overhead of dynamic dispatch and such that you have with Objective-C. 
The C++ subset they support is quite like the Embedded C++ I mentioned, but
I don't think they picked up that spec exactly.

bhahn at transoft.mmangle.net   <-- unmangle address to reply