Messages in this thread | | | Date | Tue, 12 Jan 1999 20:52:39 +0100 | From | Marc Espie <> | Subject | Re: C++ in kernel (was Re: exception in a device driver) |
| |
In article <000c01be3df6$f721f700$04c809c0@Fake.Domain.com> you write:
>>You'd just have to borrow some of the EGCS library and put it into the >>Linux 'lib' directory, so it's always available. No biggie.
>It will be a biggy, the unswapable kernel will become much larger in size. >While I'm on this point, since templates are generate instataneous code for >any object that happens to use that templatized code, multiple copies of >what is esentially the same code will be generated; inflating the unswapable >kernel size even more.
C++ under linux 101: multiple instantiations in different object files get resolved at link-time thanks to gnu-link-once, unless you mis-controlled inline at some point.
and C++ standard trick (hell, it's even mentionned prominently in Stroustrup): it's trivial to use template specialization to ensure that, for instance, any List<T*> operation gets implemented thru List<void *>, the List<T*> being there to enforce type safety.
This is *BASIC* C++.
I'll readily admit that C++ is probably not right for the kernel from a human point of view. But technically ? Do your homework... C++ has changed during the last ten years, most problems that used to exist have been addressed at one point or another.
There are techniques being implemented nowadays that avoid code-bloat. The one I just mentionned for instance. Look in C++ reference texts, for things called `traits', or `empty base optimization'. These should be standard on almost all compilers. Good ones such as Kai C++ implement a good enough language that it can beat Fortran 90 on its homeground, and egcs is getting there awfully fast.
- 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/
| |