Date: Thu, 20 Jul 2006 11:39:27 +1000 From: David Nugent <davidn@datalinktech.com.au> To: Matthias Andree <matthias.andree@gmx.de> Cc: freebsd-hackers@freebsd.org, delphij@delphij.net, Julian Elischer <julian@elischer.org>, mag@intron.ac Subject: Re: kern/99979: Get Ready for Kernel Module in C++ Message-ID: <44BEDECF.5010609@datalinktech.com.au> In-Reply-To: <m3sll8bkoi.fsf@merlin.emma.line.org> References: <200607092136.k69LaNDX055391@www.freebsd.org> <84dead720607092015q7f1701abse143f3855c2aa95a@mail.gmail.com> <1152540567.99616@origin.intron.ac> <44B2AE69.4080703@elischer.org> <44B2D2DF.2000401@sh.cvut.cz> <m3sll8bkoi.fsf@merlin.emma.line.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthias Andree wrote: >> Deciding that some features are bad beforehand, before you evaluate them >> is IMO bad idea. Let interested people write a bunch of C++ modules with >> the complete language before deciding on what shouldn't be used. >> > > No, that won't work -- plus you need a bunch of run-time support > (libstdc++ isn't exactly something that belongs into the kernel you know). > libstdc++ would not be used, just as userland libc isn't. There is a spec for embedded C++, and it is certainly appropriate to kernel level development. Many parts of the language that require runtime support can be dropped with impunity; for example most embedded environments don't include for exceptions , rtti, many don't support objects at module scope with constructors/destructors, and so on. C++ itself is quite usable in an embedded environment, but you don't (and should not expect) to get the complete feature list of the mainstream language.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44BEDECF.5010609>