On Mon, Jan 05, 2009 at 02:29:19PM +0100, Erik Wikstr??m wrote: > On 2009-01-05 12:33, Jeremy Chadwick wrote: > > On Sun, Jan 04, 2009 at 05:06:13PM +0100, Michael Neumann wrote: > >> This question bugs me since a quite long time so I write it down... > >> > >> FreeBSD had a long thread about pros and cons of using C++ > >> in the kernel here [1]. > >> > >> I'm undecided whether it would be good to use C++ in the DragonFly kernel. > > > > Regardless of what folks decide, I ask that everyone keep one thing in > > mind (which so far in this thread has not been mentioned): > > > > This is an open-source project. What guarantee is there that all > > members of the project (at the time, or in the future) are going to > > understand all the intricacies and C++ nomenclature? > > > This story is not meant to reflect on C++ the language. I hope readers > > understand the point of the story, and take into considerations the pros > > and cons of said choice. > > That is a very important consideration, however I would like to point > out that for kernel development only a very limited subset of the C++ > language would be used. I would assume that the most desirable features > would be 1) real classes with member-functions as opposed to structs and > functions that work on them, 2) inheritance, 3) constructors/ > destructors, and 4) templates, which are quite easy to understand.
Is the current code bad or something? What exactly is the problem that can be "solved" with C++? For argument's sake, how would you feel about someone suggesting you introduce Java, or even Perl, into the core of a C based project? This might seem ridiculous, but I think this get's proponents of C++ closer to thinking like those that balk at the very thought of "polluting" the C code base. Introducing languages with such features is not only asking for others to learn new syntax, but a completely new paradigm. And when this happens, is it even the same project anymore? My answer is, no. And if you say that no new paradigm is needed since C syntax is encapsulated within C++, then what's the point of even switching? Mixing languages is bad enough, but mixing paradigms is orders of magnitude worse. So, if you're not going to take full advantage of a language's features *everywhere*, what is the point? I should note that a personal friend of mine who works for M$ tells me that while they use C++, they most certainly do not make judicious use of it's OOP features. In fact, he told me that most of the code he's seen and worked on uses C++ as nothing more than a fancy way to manage C-style structs as classes. So again, what's the point? > > Of course, to be honest I don't see C++ in the kernel any time soon (or > ever) since I expect that just the work on getting the infrastructure in > place would be quite high (getting new to work as it should, probably > some compiler and linker issues, etc.). I think it goes back to the point of not alienating the vast majority of your contributor base. Learning the mindset of how a project uses a particular language should be a minimal curve. Most energies should be spent on solving the hard problems brought on by the project's goals. Cheers, Brett > > -- > Erik Wikstr??m
