| |||||||||||||
Quote of the weekQuote of the weekPosted Dec 9, 2004 4:04 UTC (Thu) by josh_stern (guest, #4868)Parent article: Quote of the week
That's sort of like pointing out how awful it would be to program a
(Log in to post comments)
Quote of the week Posted Dec 10, 2004 2:57 UTC (Fri) by mbp (subscriber, #2737) [Link] The thing is that because C is a simpler language, it is easy to describe the necessary rules: no #ifdefs in code, avoid macros, strongly avoid macros don't generate "self-contained" results, use inlines rather than macros where possible, etc. These are easy to understand, easy to check for, and most experienced programmers will see they make sense.
For C++ in principle you can decide to avoid some features, but it is hard to agree on which ones. I have heard people propose any of the following: no templates, no MI, no RTTI, no non-virtual members, no typedefs, no operator overloading, etc. And yet if you stick to just slightly-improved C then people will complain...
Quote of the week Posted Dec 10, 2004 4:37 UTC (Fri) by josh_stern (guest, #4868) [Link] The quote above and my response both speak to the same programmingprinciple: don't change the global namespace and/or default builtin operations in unexpected ways. That's a principle of good practice that isn't practically reducible to a set of specific syntactic. My point was that the worst abuses are equally possible in C itself, and it is actually easier to check for abuse in common C++ idioms(i.e. #define is more easily avoided and operator definitions at global scope are easy to notice and/or check for). I don't advocate changing kernel development practice, but the quotation, taken out of context, was simply wrongheaded. A statement like this: "C++ would be bad for kernel development because fewer practitioners have sufficient mastery of that language" isn't something I would care to dispute.
Quote of the week Posted Dec 10, 2004 6:58 UTC (Fri) by mbp (subscriber, #2737) [Link] Ted's response has nothing to do with changing the global namespace or default builtin operations. That statement can cause trouble if any of a, b or c are of types defined to behave in a surprising way. And while it is possible to write surprising code in any language, it is common (almost unavoidable) in C++ to write code which can have surprising interactions. It is generally a reasonable assumption in C that there are no macros that will mess with a line; it is not a reasonable assumption in C++ that there are no conversion or copy constructors or operators.
C++ has more magic, therefore it is harder to look at code and see what it does without examining all of the definitions which may be in force.
Quote of the week Posted Dec 10, 2004 18:39 UTC (Fri) by josh_stern (guest, #4868) [Link] "Ted's response has nothing to do with changing the global namespace or default builtin operations. That statement can cause trouble if any of a, b or c are of types defined to behave in a surprising way."
Huh? I must be giving Ted more credit than you apparently do. I assumed he was worried about the possibility that someone had redefined global assignment or addition operators for POD (built-in) or standad types or known types which use a default assignment operator. That would be analogous to creating some weird and unexpected macro that made normal looking code into something utterly different. Such things should be ruled out by coding standards that are fully comparable to 'Minimize macro use and always use captial letters for macro names'. "Surprising" behavior by user-defined member functions is not something that would cause diagnostic problems for a competent developer, because a) we don't have much prior expectation on the behavior of a new user-defined type, and b) the member function declaration and definition has to be part of the class declaration and definition, so we know exactly where to look for it and who is supposed to be modifying it (so someone cannot come along and redefine it in an unrelated header file). It is part of basic developer competency to know which types are being operated on, and understanding that the argument type is actually part of the function name in C++ is not a huge mental leap.
"And while it is possible to write surprising code in any language, it is common (almost unavoidable) in C++ to write code which can have surprising interactions."
It's not common for competent C++ developers to write code that is seen as having surprising interactions by competent C++ developers.
"It is generally a reasonable assumption in C that there are no macros that will mess with a line; it is not a reasonable assumption in C++ that there are no conversion or copy constructors or operators."
Copy constructors and assignment operators are a basic part of C++. There is nothing surprising about them - every class has one copy constructor and one assignment operator, default or otherwise (though they can be made private members to eliminate their actual usage). Other member function operators, global operators, and type conversion member operators all have their place in some types of coding, and there are various coding standards describing their appropriate usage. Moreover, they could all be prohibited from a given type of project without seriously impacting common development idioms.
"C++ has more magic, therefore it is harder to look at code and see what it does without examining all of the definitions which may be in force."
ISO C++ is a more complicated, larger language than C99. One only needs to look at the standards documents for each to see how much larger C++ is. This means that C++ takes that much longer to learn well, and this is a serious criticism of it as a language (both in comparison to C and to Java).
But I disagree with the statement above in the sense that it is actually easier for a competent C++ developer to inspect and/or debug application code written by another competent C++ developer. There are a lot of reasons for that, of which I'll highlight a few: a) compactness/locality of class member declarations, definitions, and access control, b) encapsulation of resource acqusition and release mechanisms, c) namespace separation that is independent of header separation, d) less need/usefor macros, e) stricter typing, and f) more utility built into presumably debugged standard library code (I realize this is irrelevant for kernel programming).
Quote of the week Posted Dec 10, 2004 8:37 UTC (Fri) by daniel (subscriber, #3181) [Link] Hi Martin,
"The thing is that because C is a simpler language, it is easy to describe the necessary rules: no #ifdefs in code, avoid macros, strongly avoid macros don't generate "self-contained" results, use inlines rather than macros where possible, etc. These are easy to understand, easy to check for, and most experienced programmers will see they make sense."
If it was C++, we'd add the rule "no operator overloading", big deal. This argument, like many I've seen for the "against" case, baffles me. The only argument that really matters is: it's Linus's kernel and he doesn't want any C++ in it. But I do wonder how many of the "against" crowd have actually used C++ on a project of any significance?
John Carmack developed the Doom III engine in C++, his first engine written in C++. Where John goes, there is usually truth. I don't know what his reasons were, but my impression is, C++ is an altogether more regular and descriptive language than plain old C, and superior for large projects. One small example: with C++ templates we could have type checking in the list ops, instead of having every list be (struct list_head *).
But I don't mind sticking with C. I'm an oldtimer who learned to code before there was any such thing as C++. I'd just as soon things stay as they are, at least until I get time to improve my C++ skills. I suspect that C++ _is_ actually better for a large OS project, but that somebody will actually have to sit down and prove it by building a whole kernel in it, and that may take a while.
Quote of the week Posted Dec 16, 2004 22:33 UTC (Thu) by renox (subscriber, #23785) [Link] > John Carmack developed the Doom III engine in C++
How many developers worked on the engine of Doom III?
|
|||||||||||||