| |||||||||||||
Quote of the weekQuote of the weekPosted Dec 10, 2004 18:39 UTC (Fri) by josh_stern (guest, #4868)In reply to: Quote of the week by mbp Parent article: Quote of the week
"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).
(Log in to post comments)
|
|||||||||||||