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
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"