"Hargett, Matt" <matt.harg...@bluecoat.com> writes: >> As noted earlier I think we do want to use some STL classes. > > I agree with Mark's earlier declaration that it is relatively > straight-forward, low-hanging fruit to replace VEC_*
I do not object to simple and obvious uses of STL to replace equivalent functionality, but I've seen code that layers STL over STL over STL to the point where the code is very difficult to understand. Hence, my recommendation to avoid STL *at first*. It teaches caution against over-abstracting and arbitrary complexity. >> 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. Again, my goal is to encourage good practices (i.e. complete and up-to-date comments) easier to follow by giving them the easiest syntax to deal with (i.e. any editor can edit them easily, any reader can read them easily). 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. > In other (more sane) cases, an editor of choice has a bug in one of > its extensions that needed fixing, Or is completely lacking the language-aware extensions needed to deal with such things, but has a simple "reformat paragraph" function. Or has no such function so must be manually reformatted. > 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? Once you've seen a heirarchy with dozens if not hundreds of members and wild multiple inheritance schemes, you'll understand.
