I think this was intended to go to the list, as will my reply:
Using object structuring in the code isn't the source of the performance problem. I'll probably retain a lot of that, especially as I'm converting from C++.
In a few cases, there are divisions of labor that are distributed across two or three object types, and imposing object structure in these cases tends to obscure more than it clarifies. In those cases I'll violate the usual object-oriented conventions.
The other exceptional design pattern I intend to use has to do with type subversion. In driver code in particular, it's useful to have things in structures of the form:
struct DriverInterface {
void *someDriver;
retval method(void *theDriver, args-with-known-types)
};
where you know (by virtue of coding convention) that someDriver will always be of the form "struct X *" and that the method will always expect "struct X *" as it's first argument, but X won't always be the same type. This is one of the places where C++'s abstraction abilities are weak. You'ld like a means to have a pointer to method whose class type is abstracted. Unfortunately, the compiler cannot really resolve this correctly in the face of virtual function tables.
Jonathan
> Thanks, I really appreciate the detailed explanation of why you are
> switching to C. These aren't issues I normally have to deal with.
>
> "Jonathan S. Shapiro" wrote:
>
> > Look, I'm all for OO languages. Hell, I wrote a book on how to use one
> > effectively. Objective C and Java certainly have a great deal of appeal,
and
> > if I could get a Java to native compiler I'ld very happily write all
domain
> > code in Java.
> Just curious, but does this mean you'll be using an OOP technique for
> C? Or would this be to ugly or have too much overhead to be worth
> while?
>
> > But not in the kernel. In the kernel, the rubber has to meet the road in
a
> > very precise way, and all of the current OO languages introduce
overheads
> > and unpredictabilities that make them non-starters for kernel
> > implementations.
> >
> > Meanwhile, does anybody know of a good Java to native code compiler?
>
> I don't know about the "good" part, but I know that gcj exists. I think
> they mostly lack library support, paticularly in the gui field.
>
> Ron
> KB0NUV
>