Messages in this thread | | | From | "Brian Macy" <> | Subject | Re: C++ in kernel (was Re: exception in a device driver) | Date | Mon, 11 Jan 1999 10:06:18 -0800 |
| |
>On the contrary >foo1.C > blah->foofunc(); >foo2.C >blahobject::foofunc() >{ > printf("Hi"); >} > >a C++ compiler ends up passing "this" needlessly because it can't tell that >foofunc of object blahobject need not know who it is. > >Thats only one example.
If the programmer makes foofunc a static member function you're fine (or in this case static and inline). This would only be a problem if you wanted it to be a virtual call, in which case the extra few bytes on the stack is the least of your performance worries. Anyways, the code being called chooses how it can be called to perform best.
A colleague and I have a templated vector class (actually an evolution of a class library that was started 10 years ago) that makes a good abstraction and blows asserts in debug versions, but in release versions it is equivalent to a new'd pointer and a size being passed around.
I'm not advocating C++ in the kernel, but for other reasons than performance. - bad C++ is worse than bad C - I'd prefer my compiles not to take a lot longer - I don't trust the gcc compiler to parse and optimize correctly... I have problems enough with the commercial Windows compilers (Watcom, Borland, Microsoft). I deal with it in applications but don't want to play this game with my kernel.
Brian Macy
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |