From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 14:26:29 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D52116A417 for ; Thu, 15 Nov 2007 14:26:29 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3C6CF13C478 for ; Thu, 15 Nov 2007 14:26:29 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 1E0D948912; Thu, 15 Nov 2007 09:26:26 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 15 Nov 2007 09:26:26 -0500 X-Sasl-enc: VjAIC+nC0gQNQZdEGhVLs3m911+EYUZMlm47ch0xQryl 1195136785 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 782FBE20F; Thu, 15 Nov 2007 09:26:25 -0500 (EST) Message-ID: <473C5710.7040909@incunabulum.net> Date: Thu, 15 Nov 2007 14:26:24 +0000 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Andrew Reilly References: <4722BDBE.5030408@incunabulum.net> <20071028.000300.-861062412.imp@bsdimp.com> <20071115130058.GA71758@duncan.reilly.home> In-Reply-To: <20071115130058.GA71758@duncan.reilly.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: C++ in the kernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2007 14:26:29 -0000 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