> >> I'm not sure i agree with this, because I don't see anything wrong > >> with multi-line C++-style comments. > > > > I'm with Ian on this one. Is there a reason for this, other than > one's > > personal tool preference for editing code may make C-style multi-line > > comments easier to add/remove? > > Anything that makes comments harder to maintain, I'm against. But > there's a grey area for 2-5 line comments preceeding a line of code, > for > example. I'd really hate to see 50 lines of formatted paragraphs and > diagrams, each with "//" at the beginning, when a single /* at the > beginning and */ at the end would do just as well and avoid decorating > every single line of what is essentially documentation.
That makes sense, though I can still see it both ways. Sticking with the existing C-style comment standard in order to avoid mixed-style comments would probably make things the easiest for all the existing developers. > As for personal tool preference, I prefer emacs, which is one of the > editors that *can* deal with C++-style block comments, and I still want > to avoid them. You've already convinced me, but you originally described a problem where emacs' paragraph formatting would incorrectly rearrange multi-line C++ comments. Out of personal curiosity, does emacs actually have a bug in this regard or not? > > One thing I disagree with in the wiki is the complete disallowance of > > multiple inheritance. > > Multiple inheritance is evil. IMHO class heirarchy reflects an "is-a" > relationship, and one thing cannot be two things. It gets worse when > the two immediate ancestors are derived from a common ancestor, and it > becomes less obvious which path is taken to get to the common methods > and data. If you need to add child-specific intelligence to a method, > which ancestor's method do you call next to continue processing? Who > calls the common ancestor? Multiple inheritance of behavioral classes should indeed be avoided in pretty much every case -- on this I agree. For many who lived through a multiple-inheritance apocalypse, the phrase multiple inheritance often becomes a sort of a puritanical "bad word". It is more than possible, as I have proven in several professional contexts, to use multiple inheritance of pure interfaces (along with favoring delegation) as a way to avoid/remove duplication of implementation code, duplication of declaration, parallel inheritance hierarchies, and inappropriate casting that violates the Liskov Substitution Principle. That being said, you have a very valid point that many people (even those with many years of experience with C++) don't have a firm enough grasp of what *not* to do with regard to inheritance and object-orientation. As I said in my previous message, I would suggest introducing a new warning that trips when a class multiply inherits from non-pure virtual classes (not counting empty virtual dtors). This would help people be aware of when they inadvertently multiple-inherit non-interface classes so they can refactor away from the situation. (Typically, by extracting a pure interface class from one of the behavioral classes, inheriting from the interface, and delegating to the implementation class.) Said warning could also act as an enforcement, just in case GCC code reviews happened to miss the situation. As far as implementing said warning, it seems like the virtual dtor warning could be used as the basis for this new warning. > Once you've seen a heirarchy with dozens if not hundreds of members and > wild multiple inheritance schemes, you'll understand. My primary job is helping companies with legacy codebases untangle their often completely ridiculous webs of various coding problems. I've lived through the nightmare you describe in both massive C++ projects, as well as with the practice of "monkey patching" on Ruby projects. I have arrived at the recommendation I make from both having to help dig existing teams/companies out of holes involving extreme uses of multiple inheritance, but also from creating new C++ codebases where a strict single-inheritance policy was adhered to and seeing what issues eventually came about from that extreme. What do you think of a guideline that says "multiple inheritance is discouraged in general, but if you think multiple inheritance of pure-virtual (interface) classes is better than the alternatives, email the list and/or module maintainers for specific guidance"?
