Object-oriented design patterns in the kernel, part 1
Object-oriented design patterns in the kernel, part 1
Posted Jun 3, 2011 22:56 UTC (Fri) by chad.netzer (subscriber, #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
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.
Posted Jun 3, 2011 23:43 UTC (Fri)
by daglwn (guest, #65432)
[Link] (1 responses)
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.
Posted Jun 4, 2011 0:21 UTC (Sat)
by chad.netzer (subscriber, #4257)
[Link]
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
> the kind of concrete questions that you claimed were not the right ones.
> 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?
> incorrect, btw.
uses") is arguably one of C++'s *worst* additions to the C language
Object-oriented design patterns in the kernel, part 1