Re: Non C++ IOKit driver
Re: Non C++ IOKit driver
- Subject: Re: Non C++ IOKit driver
- From: Jose Commins <email@hidden>
- Date: Fri, 9 May 2003 14:06:58 +0100
Brian, a Most Excellent post, along with others on this list actually!
From what I gather then, I can make do with my basic understanding of
C++ and its way of dealing with things and not need to deal with any
unreadable C++ kung-fu. I still need to have a better understanding of
C++ overall, but I still get the impression from what I have seen in
the sample code that Obj-C would have been a more elegant solution (I'm
not an OO guru, so I may be at a loss as to why the drivers were
changed to C++ if they started as Obj-C).
Still, from my standpoint, by the people in question at Apple choosing
embedded C++ rather than the full-blown version was a damn good
decision - coming from a practical low-level embedded background I've
seen the havoc a full C++ implementation can wreak on a core system
(bad bad bad bad bad).
Regards,
Jose.
On Wednesday, May 7, 2003, at 08:11 PM, Brian Willoughby wrote:
From: Brian Willoughby <email@hidden>
Date: Wed May 7, 2003 7:58:00 AM Europe/London
To: john <email@hidden>
Cc: email@hidden
Subject: Re: Non C++ IOKit driver.
[ I had been considering (very non-seriously) writing some kind of
[ wrapper to the IOKit to use ObjC since I don't really like C++,
[ but I doubt I ever will :)
The precursor to IOKit, known as DriverKit, was written entirely in
ObjC. The
ObjC RunTime is finely tuned, with caching for the method lookup
tables, so
the performance is very high. According to the 1997 WWDC sessions,
ObjC
messaging compared almost exactly with library function calls down to
the
cycle. Not quite sure what they were comparing exactly, because I
couldn't
find my notes from 1997 ;-)
I do know that ObjC objects mix quite well with Java objects (see
WebObjects),
but I haven't heard much about mixing ObjC with C++ objects. ObjC++ is
certainly possible, but not many have reported on something like what
you
consider.
[ In any case, C++ is relatively painless if you avoid the
[ complexities.
You must avoid the complexities when programming in IOKit. Reading
from the
Inside Mac OS X: I/O Kit Fundamentals, "It is based on an
object-oriented
programming model implemented in a restricted form of C++ that omits
features
unsuitable for use within a multithreaded kernel."
Reading further along:
"Apple considered several programming languages for the I/O Kit and
chose a
restricted subset of C++. This subset is based on the Embedded C++
specification (www.caravan.net/ec2plus/).
...
The restricted subset disallows certain features of C++, including
* exceptions
* multiple inheritance
* templates
* runtime type information (RTTI) - the I/O Kit uses its own
implementation of
an runtime typing system
These features were dropped because they were deemed unsuitable for
use with a
multithreaded kernel. If you feel you need these features, you should
reconsider your design. You should be able to write any driver you
require
using I/O Kit with these restrictions in place."
I miss the ObjC-based DriverKit.
There was no good reason to switch from ObjC to C++.
Brian Willoughby
Sound Consulting
--
The law of gravity says, "no fair jumping without coming down"
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.