C++ in the kernel

[Bruce M Simpson]

Andrew Reilly wrote:
> Could that be done with cfront (C++ to C translation)?  From
> memory, cfront didn't do exceptions or rtti either, as they had
> not been invented yet.
>   

The thing is Stroustrup has come out and said that eC++ is pretty much 
not worth bothering with.  Based on my experience in working with C++ on 
project XORP, I am inclined to agree with him -- the usefulness of C++ 
is degraded without these features.

The point which invoked the original discussion, keeping this 
compiler/toolchain agnostic for the moment: the fact the Netlab team has 
shown it is possible to implement C++ exceptions for a kernel target, in 
a manner which has acceptable performance characteristics for that kind 
of target.

RTTI is a separate issue from exceptions. Usually it just amounts to an 
additional slot in the vtbl to allow the type of the object to be 
determined; and the depth of the inheritance graph.
Beyond this, any additional cost is due to how the compiler implements 
RTTI -- naming conventions and linkage conventions are the real issue here.

I don't doubt that how RTTI is implemented in GNU C++, for example, is 
likely to lead to bloat, so I am inclined to agree with you that RTTI is 
best avoided, for the time being, in kernel context -- although the 
benefits of dynamic_cast in capturing shared semantics speak for themselves.

Based on my experience with C++, I would be more concerned about the 
potential misuse of templates for introducing bloat. One has to be very, 
very careful about how meta-classes are implemented.

It is possible to capture a lot of common semantics in a large software 
project using templates, and obtain the benefits of code reuse without 
sacrificing performance, but, as I have said earlier in this thread, the 
tool has to be wielded carefully to get these benefits.

regards,
BMS