| |||||||||||||
Object-oriented design patterns in the kernel, part 1Object-oriented design patterns in the kernel, part 1Posted Jun 2, 2011 17:54 UTC (Thu) by chad.netzer (✭ supporter ✭, #4257)In reply to: Object-oriented design patterns in the kernel, part 1 by daglwn Parent article: Object-oriented design patterns in the kernel, part 1
Which C++ keywords/features, in your opinion, should one be able to use in kernel code (since we are explicitly talking about using a subset of C++). Also, how do I, as a C contributor, deal with things like someone accidentally overloading my foo(int) function with foo(char), and other such issues? Ie. Who is in charge of enforcing the correct subset of C++ on a project with such a wide range of contributors, since compiling in C++ typically gives you access to *all* of C++, not just the subset you prefer?
Btw, the inheritance model that you tout as a feature (for "simple uses") is arguably one of C++'s *worst* additions to the C language; there is a reason that no one else ever copied it (AFAIK). Where do you draw the line on how much of it to use?
(Log in to post comments)
Object-oriented design patterns in the kernel, part 1 Posted Jun 2, 2011 21:01 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Well, other projects manage to do it just fine. For example, see: LLVM, QT, OpenOffice, FireFox, Chrome and so on.
Object-oriented design patterns in the kernel, part 1 Posted Jun 2, 2011 22:08 UTC (Thu) by chad.netzer (✭ supporter ✭, #4257) [Link]
Which of those projects started as a large C codebase, and migrated to C++? I mean, that is what we are discussing, unless you are proposing redesigning the Linux kernel from scratch, using C++. Do we allow device drivers to be C++, but still use the core C kernel code? Or do we require the device drivers to be C, but redesign the core with C++? What subsystems would benefit *immediately* from being rewritten in C++? These are questions without obvious answers, imo.
I'd bet a kernel project that was started from scratch using C++, could probably *not* sustain the rate of development that Linux has seen, given the nature of it's contributor base. Those projects you mentioned all started in C++ (AFAIK), typically with a small focused team of programmers, all commercially funded (except LLVM, which had research funding initially), whereas Linux had an explosion of early volunteer contributors. And I'm not completely sure, but it seems that Linux still has the widest range of commercial and volunteer contributors compared to any of the other projects you mentioned. It's just not comparable; a C++ codebase *would* drastically affect the set of contributors.
Object-oriented design patterns in the kernel, part 1 Posted Jun 2, 2011 22:23 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
>Do we allow device drivers to be C++, but still use the core C kernel code? Or do we require the device drivers to be C, but redesign the core with C++? What subsystems would benefit *immediately* from being rewritten in C++? These are questions without obvious answers, imo.
Any real refactoring of Linux-sized codebases MUST be gradual. Hypothetically, I'd first clean up kernel source to allow C++ drivers, introduce kernel-side C++ library and then slowly convert subsystems to it.
Though by now it might not get us much benefit, I admit. A lot of kernel code is fairly conservative and rewriting it just for the sake of rewriting won't get us anything useful.
>I'd bet a kernel project that was started from scratch using C++, could probably *not* sustain the rate of development that Linux has seen, given the nature of it's contributor base. Those projects you mentioned all started in C++ (AFAIK), typically with a small focused team of programmers, all commercially funded (except LLVM, which had research funding initially), whereas Linux had an explosion of early volunteer contributors.
KDE started the same way - an explosion of contributors working on the same goal. By now it's comparable in size with the Linux kernel. Ditto for Haiku OS (though it can't compare with Linux).
At smaller scales, we're seeing addition of C++ to the Mesa project right now (new shader compiler and optimizer is written in C++) and it seems to be working out fine. Though they use it in C-with-classes fashion, mainly for the 'Visitor' pattern.
There are some case studies on transitioning large codebases from C to C++: http://www.bleading-edge.com/Publications/C++Report/v9507...
Object-oriented design patterns in the kernel, part 1 Posted Jun 2, 2011 23:07 UTC (Thu) by chad.netzer (✭ supporter ✭, #4257) [Link]
> KDE started the same way - an explosion of contributors working on the same goal.
But KDE was also a collection of many independent, even orthogonal, applications such that developers could work on their piece without any affect on another (ie. less code merging across larger groups, etc.) Even the dependent pieces were often linked together by abstractions at a higher level than the language (object brokers, interprocess communication protocols, etc.) right? So the real core C++ libraries and such, that were linked into programs directly were a much smaller group of developers and contributors (I'm guessing). And furthermore, a significant portion of that core was based around the commercially developed QT, which started completely as C++ (and hell, even extended it) and was a small tight team. KDE is definitely a great example of a large and active C++ based project, but still, I think, a *very* different contribution model than a community driven C++ monolithic kernel would be. It all comes down to merging, and merging lots of separate contributed C++ code and requires a lot more pre-planning, design, discipline, coordination, and review *just at the language level* than C (imo).
However, my summary of KDE could be wrong, so someone please correct me if so. I've not used it much personally.
Object-oriented design patterns in the kernel, part 1 Posted Jun 2, 2011 23:20 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Kernel is not exactly monolithic as well. It has various loosely-linked subsystems and a lot of code is in drivers. Also, I'd like to point out that the core in Linux initially was quite small as well.
Ah, and I've forgotten about another large C project switching to C++ - http://gcc.gnu.org/wiki/gcc-in-cxx
Object-oriented design patterns in the kernel, part 1 Posted Jun 3, 2011 2:34 UTC (Fri) by chad.netzer (✭ supporter ✭, #4257) [Link]
> Kernel is not exactly monolithic as well.
Sure it is. Certainly in the classic sense of not having memory access isolation between all services, drivers, etc. The Linux kernel may be modular, and have some kernel threads, but it is "exactly monolithic" by the standard definition, is it not?
Thus, it isn't paranoia on the part of the developers to use a language that allows one to fairly easily see what memory accesses are occurring on a roughly line per line basis (such as C).
> Ah, and I've forgotten about another large C project switching to C++ (gcc)
That's interesting, because the gcc development seems so different from Linux's; things like the copyright assignment provisions may (or may not, I'm speculating) affect the contributor pool in a way that makes the transition more practical. In any case, compilers work at a different level, so that the memory access abstractions of C++ aren't so objectionable. In fact, I suspect hey have more data structures and inheritance possibilities that would benefit directly from it, and it's probably a good choice for them. But I don't think that necessarily translates into a reason for a kernel project to do the same.
In any case, while I disagree with daglwn's assertion that Linus was "flat out wrong" about C++, it's exciting to see projects that implement a kernel in a language like C++ (or D, or Go, etc.) to know how the language features influence design decisions and ease of implementation, to see if it really matters.
Object-oriented design patterns in the kernel, part 1 Posted Jun 3, 2011 14:46 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
>Sure it is. Certainly in the classic sense of not having memory access isolation between all services, drivers, etc. The Linux kernel may be modular, and have some kernel threads, but it is "exactly monolithic" by the standard definition, is it not?
I don't mean 'monolithic' in the sense of 'monolithic vs. microkernels'. I meant it in the sense of 'one giant C file vs. modular code'.
Linux Kernel is divided into subsystems which are pretty independent: network layer doesn't really care about DRI, for example.
>In any case, while I disagree with daglwn's assertion that Linus was "flat out wrong" about C++, it's exciting to see projects that implement a kernel in a language like C++ (or D, or Go, etc.) to know how the language features influence design decisions and ease of implementation, to see if it really matters.
It doesn't look like that C vs. C++ matter much in kernel development (look at L4 kernel, for example).
Object-oriented design patterns in the kernel, part 1 Posted Jun 3, 2011 17:49 UTC (Fri) by chad.netzer (✭ supporter ✭, #4257) [Link]
> I don't mean 'monolithic' in the sense of 'monolithic vs. microkernels'.
Well, that's confusing then. The term already has meaning in kernel discussions, and you were responding to *my* usage of the term. But, ok.
The concerns I mentioned still apply for pretty independent codebases: if you intend to build the whole kernel with C++, you have do deal with all the legacy C code and interaction issues (function namespace, type incompabilities, etc.) so as you said it must be gradual. But, if it's gradual, you now have a complicated mixed build system and have to worry about how to interact across the C/C++ layers (since there is no agnostic "message passing" layer for the components, like a microkernel would have). It could be done, I'm sure, it just a matter of what is motivating it.
It might make sense if there already existed some well tested code bases that were worth integrating; let's say hypothetically that ZFS had been released as GPL years ago, but it's implementation was in C++. Then I could see dealing with the pain (or attempting it), rather than a rewrite.
> It doesn't look like that C vs. C++ matter much in kernel development (look at L4 kernel, for example).
Well, L4/Fiasco *is* a microkernel, with a well defined message passing ABI, built by a small team, and is *tiny*. But it demonstrates that design of the OS is the much bigger issue than language implementation for the most part. The language issue really matters more (imo) from a community and potential contributor perspective.
Haiku Posted Jun 3, 2011 8:48 UTC (Fri) by tialaramex (subscriber, #21167) [Link]
Haiku is a really terrible example.
In their kernel they're using a subset of 1990s C++ that gives them much less functionality than the C++ aficionados have been talking about in these comments.
All non-core components use only C APIs even though they may be in C++. So many of the examples mentioned for Linux would still have to be done the same way since they're available in blessed module APIs for Haiku.
And despite a decade's work what they have is basically a BeOS clone. Nasty shortcuts to rush BeOS to market before Be Inc. ran out of money, faithfully reproduced. That goes from big picture things like no privilege separation and no power management to little annoyances like no real hot plug (they have a hack that lets them hotplug USB devices by first loading all the drivers they might want...)
Haiku Posted Jun 3, 2011 13:07 UTC (Fri) by cmccabe (subscriber, #60281) [Link]
> In their kernel they're using a subset of 1990s C++ that gives them much
> less functionality than the C++ aficionados have been talking about in > these comments.
*Everyone* is using some kind of subset of C++.
Firefox and Chrome, as well as Webkit, are using -fnoexceptions and -fnortti. This is a pretty important design choice because it means that you can't do things that can fail in your constructors, since there is no way for them to report errors except throwing exceptions.
XNU, which later became the basis of the Mac OS kernel, uses a restricted subset of C++ that doesn't allow exceptions, multiple inheritance, or templates.
If projects do use exceptions, they all do it differently. Some old Microsoft APIs throw pointers to exceptions, which the caller must then manually call delete() on. Most projects roll their own exception hierarchy. Sometimes they inherit from std::exception; other times not. Sometimes they throw other things. I heard from a friend that his team is writing new code that throws ints! Yes, new code, written in 2010, that throws ints.
Some projects use char* almost everywhere, other projects use std::string. QT has its own string class, which is supposed to be better at internationalization, that a lot of projects use. Some projects use a mix of all of this stuff. Some projects roll their own string class.
A lot of projects rolled their own smart pointer, or used one from boost, prior to the introduction of tr1::shared_ptr. Some of them work similarly, others not. Some projects barely use smart pointers; other projects use them almost everywhere.
*Everyone* is using some kind of subset of C++. Everyone is bitterly convinced that they are right and everyone else is wrong. When someone advocates "using C++," a legitimate question is "which C++"? When you add a new person to your team, you can expect to spend quite a bit of time getting him or her up to speed.
And of course, the different subsets of C++ don't interoperate that well at the library level. So when designing APIs, everyone just uses the lowest common denominator, which is C or something that looks almost exactly like it.
Haiku Posted Jun 3, 2011 15:43 UTC (Fri) by daglwn (subscriber, #65432) [Link]
> *Everyone* is using some kind of subset of C++.
Not true, and if they are, they're Doing It Wrong.
Boost, for example, places no such restrictions on the project. Instead, members use vigorous code review to ensure quality. That is the right way to go because terrible interfaces get designed in every language every day. Restricting the set of allowed language features doesn't solve that problem, it exacerbates it.
Haiku Posted Jun 3, 2011 19:16 UTC (Fri) by cmccabe (subscriber, #60281) [Link]
> > *Everyone* is using some kind of subset of C++.
> > Not true, and if they are, they're Doing It Wrong.
Really? Let me ask you: when was the last time you wrote code that used throw specifications? Or the "export" keyword for templates? Or wide character streams (wchar)? Have you ever used protected inheritance?
Wake up and smell the coffee. You're programming in a subset of C++. You are no doubt convinced that your subset is "modern" and "progressive", whereas everyone else's is "backwards" and "old-fashioned". But it's still a subset.
Haiku Posted Jun 3, 2011 21:09 UTC (Fri) by daglwn (subscriber, #65432) [Link]
This makes no sense. If this is your criteria, everyone programs in a subset of their favorite language. When's the last time you used gets()?
The point is that the tools to use shouldn't be artificially restricted. If someone wants to use protected inheritance, let them as long as they can show why it's necessary or beneficial.
Haiku Posted Jun 4, 2011 1:07 UTC (Sat) by cmccabe (subscriber, #60281) [Link]
You're mixing apples and oranges. gets() isn't a language feature, it's a library function.
> The point is that the tools to use shouldn't be artificially restricted.
You didn't answer my question. When was the last time you used those features?
You say that programmers shouldn't be "artificially restricted" from doing things that are "necessary and beneficial", but those are weasel words. The reality is, you'll just define necessary and beneficial as whatever you've been doing. So if you've been throwing exceptions as pointers, it's obviously "necessary and beneficial" for the new code to do the same. If you haven't been using throw specs, obviously the new code shouldn't have them. But you're not using a subset of the language, oh no.
As a side note, what's with the gets() obsession in these programming language debates. I don't think I was even alive the last time someone used gets() in a real program.
Haiku Posted Jun 4, 2011 1:11 UTC (Sat) by cmccabe (subscriber, #60281) [Link]
As a side note, I found this highly amusing:
http://stackoverflow.com/questions/214321/what-c-features...
Literally every comment has a completely different view of which C++ features are "evil." I don't think you can find even two distinct answers that agree. I can only imagine what a novice programmer, fresh out of school, would think after reading this :)
Haiku Posted Jun 4, 2011 5:52 UTC (Sat) by elanthis (guest, #6227) [Link]
It saddens me that it's become the norm to expect a "novice" who's had a full four years worth of a $100,000 education to have his first experience with real-world languages be a StackOverflow posting.
Object-oriented design patterns in the kernel, part 1 Posted Jun 3, 2011 15:40 UTC (Fri) by daglwn (subscriber, #65432) [Link]
You're asking the wrong questions.
Which parts of C++? All of it! But people have to develop smartly, as with any language.
Specifying a language subset is a losing proposition because there will always be some feature outside of that subset that is the perfect fit for some need in the project. Artificially restricting developers is the wrong way to go. Code review, basic rules of thumb and other such things do a much better job of ensuring software quality.
As to the inheritance model, I have heard this claim many times and never once has anyone explained their objections. What is wrong with it? C++ inherited it from Simula, so your claim that nothing else uses it is incorrect.
Object-oriented design patterns in the kernel, part 1 Posted Jun 3, 2011 18:29 UTC (Fri) by chad.netzer (✭ supporter ✭, #4257) [Link]
> You're asking the wrong questions.
Enlighten us as to the right questions.
> Which parts of C++? All of it!
On new projects, sure. C++ (imo) can be quite elegant when you code in the modern style, and not all the legacy predecessors (I started before mature templates, before exceptions, before the Standard Library, etc., and many codebases are still stuck in that age since compilers took *forever* to mature).
But that isn't what we are discussing. As I said, unless you plan to rewrite Linux from scratch in C++, any proposal on the table is about using a restricted set of features in some parts of the kernel.
> C++ inherited it from Simula, so your claim that nothing else uses it is incorrect.
My claim was that no one copied it from C++, so you're re-statement of what I said is wrong. And which languages copied C++'s design in this respect? What other language after C++ uses multiple inheritance, has virtual base classes, uses "protect" or equivalent, allows slicing, etc.? I'm happy to be enlightened if there is a language out there that said "C++ inheritance is spot on, let's copy it". Python, bizarrely enough, comes kinda close in some ways (to it's detriment).
Object-oriented design patterns in the kernel, part 1 Posted Jun 3, 2011 21:21 UTC (Fri) by daglwn (subscriber, #65432) [Link]
> Enlighten us as to the right questions.
Does this code or proposed design exhibit sound engineering given the project goals?
> As I said, unless you plan to rewrite Linux from scratch in C++, any
Why? There is nothing magical about the kernel. It's software. Even in a project transitioning from one implementation to another, there's no reason to artificial limit what people are allowed to do, especially _a_priori_.
> What other language after C++ uses multiple inheritance, has virtual
Ah, good, some concrete points.
Multiple inheritance is very useful. If a language with inheritance doesn't have it, it has a major missing feature.
Virtual base classes are trickier. They are painful, I admit, but necessary for some uses of MI. Many uses of MI don't need them at all. C++'s possible mistake was to place the decision point at the intermediate class level rather than at the "final" class level. But it's a convenience/efficiency tradeoff and I'm not totally sure the committee got it wrong..
By "protect" I assume you mean "protected." Protected methods certainly are useful. Protected inheritance, not so much but I'm sure someone has a use case for it.
Slicing is also a big pitfall. But I think it's a natural consequence of call-by-value semantics. One could argue that C++ should have made call-by-reference default but that would have broken C compatibility, a major strength of the language.
> I'm happy to be enlightened if there is a language out there that said
I don't think anyone has said that. I have not said that. To do so would be to say that the language is perfect, an impossibility in an imperfect world.
There are valid criticisms of C++. But to take that to an extreme and proclaim the C++ inheritance model "broken" or "wrong" is, well, wrong.
Object-oriented design patterns in the kernel, part 1 Posted Jun 3, 2011 22:26 UTC (Fri) by elanthis (guest, #6227) [Link]
> Multiple inheritance is very useful. If a language with inheritance doesn't have it, it has a major missing feature.
Sort of. Multiple inheritance in the C++ sense is useful simply because C++ doesn't differentiate between base classes, interfaces, and mixins. The need for multiple inheritance with multiple base classes is pretty small, and at least every example I've personally seen has been an example of bad interface design rather than a showcase for the need for MI (granted, my experience is not all-encompassing).
> Virtual base classes are trickier. They are painful, I admit, but necessary for some uses of MI. Many uses of MI don't need them at all. C++'s possible mistake was to place the decision point at the intermediate class level rather than at the "final" class level.
I will argue that if you start having intermediate classes very often at all, or a diamond tree, you're using inheritance wrong. Which most object-oriented developers do, unfortunately. A large part of this I fear is that it's simply taught wrong in schools. The classical examples of inheritance are things like Mammal->Dog, or Shape->Circle, or Vehicle->Car. These are attempts at modelling real-world "is-a" relationships inside of algorithmic data structures, which is really really wrong. It's a very long discussion to explain it in the necessary detail, and I believe Herb Sutter already did some fantastic talks on the topic (I'm having trouble Googling them though; maybe it wasn't Sutter that did them?).
Object-oriented design patterns in the kernel, part 1 Posted Jun 3, 2011 23:32 UTC (Fri) by daglwn (subscriber, #65432) [Link]
I think it's actually a strength that C++ doesn't differentiate among types of classes. It allows more flexibility and reuse. I agree with you that there should be a good case made before using MI.
How would, for example, making "mixin" a special kind of class look in the place of MI?
I'm not sure about "intermediate classes very often" part, but you certainly are correct about the diamond hierarchy. A diamond with state in the virtual base is usually poor design and causes countless headaches in constructors. A diamond without state in the virtual base (i.e. it's a pure interface) is sometimes useful.
isa inheritance is usually good design. hasa inheritance is usually bad design. For the latter, composition is almost always the way to go. If you can find examples where "isa" is the wrong thing to do, I am very interested. Myself, I tend to prefer generic code and composition to inheritance but there are obvious cases where inheritance is useful and necessary.
Object-oriented design patterns in the kernel, part 1 Posted Jun 4, 2011 0:50 UTC (Sat) by elanthis (guest, #6227) [Link]
> How would, for example, making "mixin" a special kind of class look in the place of MI?
The closest you get to what most people would consider a mixin in C++ would be the CRTP, but it's a little gimped because you can't properly specify that the "mixin" is implementing methods in an interface that the class inherits from.
e.g., if you have class Foo that implements interface IDoStuff, a mixin SimpleDoStuff might include members and methods that implement some or all of the methods of IDoStuff. There's no direct way to do that in C++, though, and so you end up with either grotesque inheritance trees or diamond inheritance.
The only way to handle common partial implementations of interfaces in C++ is to create intermediate classes, which then results in you having a ton of intermediate classes, and you start wanting to mix different sets of then, and then you end up with either (a) an uber base object replacing the interface, making all your object bloated and over-complex, (b) a metric crapload of intermediary classes with tons of code duplication, or (c) diamond hierarchies and virtual bases and all the problems those impose.
> isa inheritance is usually good design. hasa inheritance is usually bad design. For the latter, composition is almost always the way to go. If you can find examples where "isa" is the wrong thing to do, I am very interested. Myself, I tend to prefer generic code and composition to inheritance but there are obvious cases where inheritance is useful and necessary.
We perhaps are using slightly different definitions of "is-a", as I wasn't including interface derivation in that statement. Composition is the opposite of what I consider is-a. Yay for ambiguity in computer terminology. :)
(On a related note, composition is super important. Not understanding composition is the other thing that leads to massive inheritance trees and horribly screwed up architectures. Composition isn't necessarily trivial in C++ due to a lack of language/syntax support, but it's still possible to do and do well, unlike mixins which are borderline imposssible.)
Object-oriented design patterns in the kernel, part 1 Posted Jun 3, 2011 22:56 UTC (Fri) by chad.netzer (✭ supporter ✭, #4257) [Link]
> Does this code or proposed design exhibit sound engineering given the project goals?
That is only the right question to ask in that it must always be asked, and is contentless. Clearly a good designer will start by saying, "What is a good, sound design for this task?" But knowing how to evaluate a design and implementation requires asking the kind of concrete questions that you claimed were not the right ones.
> Even in a project transitioning from one implementation to another, there's no reason to artificial limit what people are allowed to do, especially _a_priori_.
You started this whole thread by claiming "One does not have to use every feature of a language to get good productivity out of the language.", which implied a conservative approach to feature adoption. Now you are claiming that if Linux allowed for C++ development, that all features should be available for use without restriction. Change of heart?
> Ah, good, some concrete points.
You phrase that as though I haven't already been making concrete points. I disagree, and I think I've been more concrete in my points than you have. I find Linus's arguments about using C++ for kernel coding to be largely correct (for the Linux kernel), and your defense of your assertion that he is "dead wrong" to be unconvincing.
> But to take that to an extreme and proclaim the C++ inheritance model "broken" or "wrong"
Those quoted proclamations you are apparently attributing to me are also incorrect, btw.
Object-oriented design patterns in the kernel, part 1 Posted Jun 3, 2011 23:43 UTC (Fri) by daglwn (subscriber, #65432) [Link]
> But knowing how to evaluate a design and implementation requires asking
> the kind of concrete questions that you claimed were not the right ones.
Your overarching question was, "what parts of C++?" All of your other questions were about dealing with consequences of using a subset, save the one about overloading and that one is equivalent to, "how do we make sure we don't introduce bugs?"
This is how I look at things. Given a tool, use it. Everyone on the project should evaluate how that tool is being used. If we start with a tool, reduce its functionality by saying we can't do this or that with it, it doesn't eliminate the need to evaluate how we're using it, but it does eliminate the some possibilities of using it better when we find certain cases of poor usage.
> You started this whole thread by claiming "One does not have to use
Not at all. The two statements are entirely consistent. All the tools should be available and we should make sure we use them correctly. Of course a project in transition isn't going to use every language feature immediately, simply because not all of the code will transition immediately. That does not mean that this or that language feature should be off-limits when transitioning any particular piece of code.
> You phrase that as though I haven't already been making concrete points.
Forums are a poor way to convey expression. Believe me, no disrespect was intended. I was genuinely happy to see examples as I have been asking for them in various places for a long time.
> Those quoted proclamations you are apparently attributing to me are also
Perhaps I misunderstood the intent of your statement:
Btw, the inheritance model that you tout as a feature (for "simple
If so, I apologize. It reads to me like a condemnation of the entire C++ inheritance model.
Object-oriented design patterns in the kernel, part 1 Posted Jun 4, 2011 0:21 UTC (Sat) by chad.netzer (✭ supporter ✭, #4257) [Link]
> This is how I look at things. Given a tool, use it.
I agree. Projects that adopt a tool like C++, should be prepared to adopt all of it. Those that don't want to adopt all of it, should seriously consider adopting none of it. The ones that want to adopt a subset of C++ (ie. "We'll just use it as a 'better' C, or 'C with classes'") should be prepared for the burden of that, and are probably best suited to a fairly small team of developer's (ie. not Linux sized). I think Linus was right to adopt none of it.
> The two statements are entirely consistent.
The statements themselves are not inconsistent with each other, but I feel the argument you are making with them is not, imo. But let's leave it. I think it is impractical for a large active codebase with wide collaboration to transition from C only, to fully incorporating and embracing modern C++, without a rewrite essentially from scratch. I'm not sure of any such examples in the open source world (though gcc was pointed out earlier as a related example), but perhaps I'm wrong.
> Perhaps I misunderstood the intent of your statement:
I think you were just restating my intent in your own words, but using the quotes made it appear that I said those words. I'd say 20+ years of C++ inheritance experience has shown it to be flawed: it's difficult for many to understand all the ramifications and options, carelessness leads to the fragile base class syndrome despite it's encapsulation features, people have devised the ugly "pimpl idiom" to deal with other compiler and encapsulation issues, it has multiple inheritance :), and so on and so on. I think C++ has been a useful experiment, and hopefully something better will now come to prevalence that has learned from it's flaws (disregarding Java et al; I mean a language w/ pointers).
Object-oriented design patterns in the kernel, part 1 Posted Jun 4, 2011 7:14 UTC (Sat) by chad.netzer (✭ supporter ✭, #4257) [Link] > There is nothing magical about the kernel. It's software.This got me thinking about something else. There are about 5000 uses of kmalloc() in the linux kernel, but kmalloc() takes a flag argument. So, to replace these uses with idiomatic C++ would require widespread use of placement new(). However, using placement new requires care when deleting objects. So, rather than just using delete, you have to both manually call the class destructor, and then operator delete() with the right arguments to invoke the proper delete function (I suppose the kernel C++ stdlib could kludge the delete operator so that it works for placement new; now you are writing non-conformant C++) ie. struct T *p = kmalloc(sizeof(struct T), GFP_KERNEL | GFP_DMA); some_init_function(p); kfree(p);becomes something like: T *p = new (GFP_KERNEL | GFP_DMA) T; p->~T(); operator delete(p, GFP_KERNEL | GFP_DMA); // Or whatever it takes to match the call signatureThis unorthodox usage is necessary because the kernel is not just like other software. Not when it comes to things like memory allocation. And what about a std::vector of struct *T? How do you allocate those objects with the right memory flags? Perhaps there is an elegant solution to this, most likely by eschewing bare pointers in the kernel and always using some templated smart pointer class. A fairly radical change for kernel development. What are your thoughts on it?
Object-oriented design patterns in the kernel, part 1 Posted Jun 4, 2011 7:19 UTC (Sat) by elanthis (guest, #6227) [Link]
I feel your argument is a little weak.
Video games are almost certainly "just another piece of software" and we deal with the exact same memory management types of issues. Many game engines outright ban the use of new and delete because of the problems they cause, requiring instead that specialized factories and memory managers be used, especially on console titles and mobile games. It's every last bit as complex of a set of interfaces as the kernel, if not more so. And they're still just software, and they still mostly all use C++. :)
Object-oriented design patterns in the kernel, part 1 Posted Jun 4, 2011 7:36 UTC (Sat) by chad.netzer (✭ supporter ✭, #4257) [Link]
Whereas the existing kmalloc/kfree idiom is quite straightforward. So where is the gain? If the most basic memory allocation features of the language have to be banned from use, it's hardly a sales point for adopting the language. You use it *in spite* of these deficiencies, just as Linux does with C.
Object-oriented design patterns in the kernel, part 1 Posted Jun 5, 2011 19:32 UTC (Sun) by elanthis (guest, #6227) [Link]
C++ has problems. The thing is, no other language is better. Sure, C is clearer about memory allocation. But it lacks critical things like templates. Which also have problems, but without them it's literally impossible to write a sane container library, generic algorithm library, or even a simple sort that doesn't end up making logN function calls. Dynamic languages or languages like C#/Java almost manage this, but either screw up safety or just totally screw up performance and memory usage in their generics implementation.
And then there's user-defined value types. Trying to do basic graphics work in any language other than C/C++ is a nightmare, because your vectors are referece types. In games, I use vec3's and vec4's more often than I use int's and float's. Now imagine if every number in your language of choice was a reference type. That's what doing games (or just about any other interesting mathematical application) in every single popular language besides C/C++ is like. C's failing here is the lack of operator overloading for user-defined types, which just makes doing simple expressions with vec's and such a total pain. Even languages supposedly focused towards games or systems programming, like C#, utterly fail when it comes to user defined types.
And then in the C/C++ realm, C++ actually solves the very memory management problems we started talking about through it's ability to let users define their own handle types. Raw pointers in C++ present a lot of problems that also exist in C, but C lacks the ability to solve those problems at a language/API level like you can in C++.
So yeah, C++ fails in many ways, and fails hard. Every other language just fails even harder (for certain classes of application, that is). D comes closest to being a viable replacement, but it's not better enough to justify breaking compatibility with all the excellent C++ libraries out there.
Object-oriented design patterns in the kernel, part 1 Posted Jun 6, 2011 19:17 UTC (Mon) by cmccabe (subscriber, #60281) [Link]
In my opinion, video games are a great example of a place where you *should* use C++. Kernels and systems-level software are a great example of a place where you should *never* use C++.
Why do I say this? Well, C++ was designed to increase the speed of development and allow you to mix high-level and low-level code easily. It is very good at doing those things. At the same time, a clever programmer can get reasonable performance out of C++ by spending a little time optimizing.
When writing a video game, you don't care that much about long-term maintainability or safety. An exciting game that crashes a few times a month will sell many more copies than a boring game which is rock-solid. Stuff gets rewritten from scratch every few years to take advantage of the latest and greatest hardware. If things are not written in the absolute most efficient way, who cares? You just keep tweaking things until the game runs all right on the target hardware.
Kernels are the opposite. There are still pieces of code in the Linux kernel that go back to the early 1990s. Maintainability and stability are much more important than features or speed of development. It's important to use a simple style, in a simple programming language, that many different contributors can understand and use. Efficiency is key-- we don't have extra cycles to burn on things like std::string or std::map. In some structures, people are reluctant to enlarge the structure even by 4 bytes for performance reasons.
A lot of people claim that C++ is somehow safer than C. But this is ridiculous. C++ has all of the different flavors of undefined behavior that C does, plus many, many more. C++ has a lot of "generated code"-- default copy constructors, default destructors, and so on, that will burn you if you're not careful. Again, it's about speed of development, *not* safety.
Claiming that C++ is faster than C, or even as fast, is equally ridiculous. Even the most basic operations in C++, like iostreams, are much slower than the C equivalents like printf. Maybe some kind of theoretical perfect programmer could write equally fast, or even faster, code in C++ than C. But in the real world, programmers will take shortcuts if they exist. Let me draw an analogy-- if your wife bakes a cheesecake for you every night, you're going to get fat. Yes, in theory you could not eat the cheesecake, but it's right there.
So we're left with the real C++ advantage-- speed of development. I want to be fair here. C++ is good at doing what it does. But let's not get confused here-- it's not the right choice for a lot of projects. Use the right tool for the job.
Object-oriented design patterns in the kernel, part 1 Posted Jun 7, 2011 3:40 UTC (Tue) by elanthis (guest, #6227) [Link]
You're making a few claims I have to disagree strongly with, but in few words as ive got to walk out the door in a few. First, I don't think you are quite in tune with game development, at least not professional game development. Stability and even security are quite important - nobody wants to be Fallout New Vegas. Second, game engines are not rewritten that often. All of the popular engines are well over a decade old, and the majority of the code has not changed in architecture at all. Most crashes you see in games are actually video driver crashes, save a few particularly poorly engineered titles.
C++ is very much a safer language. You bring up hidden code and such as if that makes it unsafe, which is silly. C++ doesnt just magically do things wrong behind your back anymore than C does. Yes, a destructor runs "automatically" but never ever unexpectedly. On the other hand, C requires programmers to cut-n-paste large swaths of boilerplate code, leading to a much higher bug count in general.
Simple fact is that there are kernels written in C++ which work very very well.
Object-oriented design patterns in the kernel, part 1 Posted Jun 7, 2011 6:13 UTC (Tue) by cmccabe (subscriber, #60281) [Link]
> First, I don't think you are quite in tune with game development, at least
> not professional game development. Stability and even security are quite > important - nobody wants to be Fallout New Vegas
Look, I'm not trying to trash game development or game developers. I know you guys have a difficult and challenging job.
But let's be realistic. If I'm the project manager and I have a choice of releasing with a crashing bug or two or releasing a game that is dull or outdated, I am going to release with the bugs. If I don't, I'm going to get fired. Nobody wants a game that looks like it should have come out last year.
On the other hand, the economics are different for some other kinds of software.
> C++ is very much a safer language. You bring up hidden code and
It's not silly at all. Every time I write class with any kind of non-trivial destructor, I have to remember to hide the copy constructor and assignment operator. If I fail to do this, a simple typo later in the program-- say typing use_foo(Foo f) instead of use_foo(Foo &f)-- could bring the program to its knees.
Or take conversion constructors or default parameters. Here's a true story of something that happened very recently. Someone on our project decided to change a function prototype from foo(int i) to foo(const MyObject &o). What he didn't realize was that there was a conversion constructor from an int to a MyObject. So when he overlooked this little gem:
The compiler happily generated this:
Needless to say, the results were not what he intended at all.
Implicitly generated code hurts. Default constructors hurt. Default parameters hurt even more. You might disagree, but I've had a lot of time to come to this opinion.
> Simple fact is that there are kernels written in C++ which work very very
Well, as I already mentioned, there is XNU, which has no templates, no RTTI, and no exceptions, but is "technically C++". Apparently the Windows NT kernel also has some kind of C++ support-- again, I think exceptions are left out, as well as who knows what else.
I would say a bigger C++ success story is the success of the LLVM project. They managed to write a very capable compiler in C++, which has been gaining a lot of momentum. One of my friends who works on the project is also one of the few people who can stump me with a C++ question. I guess it's hard to out language-lawyer the language implementers!
But oh, they don't use exceptions :) And the LLVM library is 20MB when compiled, whereas /usr/bin/gcc is 262kb.
C++ has been the inspiration for a lot of other languages like Java and Golang, and I respect it for that. It got a lot of things right, and it's still the language that I know the best. But can't we have some new ideas after all these years?
Object-oriented design patterns in the kernel, part 1 Posted Jun 7, 2011 6:24 UTC (Tue) by elanthis (guest, #6227) [Link]
Sure, there's cases where C++ bites you. There are cases where C does this, too, and there are many ways in which C++ helps you.
I doubt I'll convince you to change your opinion with anything short of a small novel, though. :)
Object-oriented design patterns in the kernel, part 1 Posted Jun 7, 2011 7:46 UTC (Tue) by jezuch (subscriber, #52988) [Link]
> And the LLVM library is 20MB when compiled, whereas /usr/bin/gcc is 262kb
Are you sure you're not looking at just the GCC driver that invokes the actual compiler?
jezuch@zx-spectrum-1:~$ du -shc /usr/lib/gcc/x86_64-linux-gnu/4.6/{cc1,cc1plus,lto1}
Object-oriented design patterns in the kernel, part 1 Posted Jun 7, 2011 18:54 UTC (Tue) by cmccabe (subscriber, #60281) [Link]
I stand corrected. I thought that binary was way too small... but ldd didn't tell me anything useful.
It's been a long time since I built gcc. Even back when I did embedded stuff, we always seemed to use prebuilt toolchains.
Object-oriented design patterns in the kernel, part 1 Posted Jun 9, 2011 14:21 UTC (Thu) by renox (subscriber, #23785) [Link]
> Implicitly generated code hurts. Default constructors hurt. Default parameters hurt even more. You might disagree, but I've had a lot of time to come to this opinion.
Sorry but C++ poor mix of features doesn't mean that those features are always bad..
Object-oriented design patterns in the kernel, part 1 Posted Jun 9, 2011 16:56 UTC (Thu) by jd (guest, #26381) [Link]
Well, no. Implicit code is (IMHO) always a Bad Thing because when the specs or compiler change, the resultant binaries will change behaviour when given the same source.
The source is a specification document, to all practical intents and purposes, which the compiler uses to generate a program. If the program can change in nature for the same specification, the specification is incomplete and insufficient.
In other words, by depending on something external (in this case, the compiler) you cannot do reliable testing. There are too many external parameters that you can never reliably take account of. Good engineering practice is to always work to reduce or eliminate the unknowables. If the compiler is any good, it'll ignore initializing to the compiler's defaults since the instructions generated by the compiler's default will already be present. If the compiler isn't any good, you really shouldn't be trusting it to be doing the Right Thing anyway.
If you explicitly initialize, you always know the state of a variable, no matter what new C or C++ standard is produced. This is guaranteed safe.
Compiler-tolerant software is necessarily well-engineered software. Yes, it's more work, but if you wanted to avoid work, you'd not be using C or C++, you'd be using a fourth- or fifth-generation language instead. The only reason to use anything in the C family is to be able to balance development efficiency with code efficiency. Higher levels of language offer better development efficiency, lower levels (Fortran, assembly, etc) offer better code efficiency. Neither is useful on its own for something like an OS kernel, which is why nobody writes general-purpose kernels on the scale of Linux in either Erlang or IA64 assembly.
(Kernels do exist in both those, and indeed in Occam, but because of tradeoffs are almost always much more special-purpose.)
Object-oriented design patterns in the kernel, part 1 Posted Jun 13, 2011 0:20 UTC (Mon) by cmccabe (subscriber, #60281) [Link]
> Plus C's lack of initialisation also hurt a lot, no?
I remember a thread here on LWN a while back where people were complaining about a performance regression in the kernel caused by zeroing struct page. So it seems that at least in some corner cases, not initializing memory is a feature. In a perfect world, non-initialization probably should be something that the programmer has to ask for specifically, rather than the default. But C was designed in the 1970s-- give it a break already.
When C++ was designed, in the mid-1980s, the decision was made to keep all the old uninitialized variable behavior and add some more. So if you create a C++ class with some primitives, and forget to initialize them in one of the constructors, they'll be uninitialized. This also applies to copy constructors. The rationale was that programmers shouldn't have to pay for what they didn't use.
Luckily there is some relief in sight, in the shape of Coverity and similar static analysis tools. These can catch most uninitialized variables.
|
|||||||||||||