Where Should You Apply Various C++ Coding Practices?

Dr. Love asks: "C++ contains a mountain of features. I am searching for a good C++ coding practice - what language features to avoid, what language features to make extensive use of, etc. In my survey of C++ coding practices, there seems to be a plethora of philosophies ranging from the stingy to the highly abstracted and elaborate. By stingy, I'm referring to those that use few of C++'s advanced features, such as Mozilla. At the opposite end of the spectrum, there are elaborate practices that make extensive use of the STL, exceptions, RTTI, templates, etc. Those who prefer the simple implementations tend to argue that elaborate practices result in inefficient, unclear, and unportable code. Those who prefer the elaborate implementations tend to argue that simple implementations are missing out on a Nirvana of reuse and clean design. Are these arguments unfounded? What has been your experience with C++ coding guidelines? What does the industry expect?" Just like the choice of the language itself, the choice of the features you use in your language should lend itself to the task you are developing. Some projects don't need to use every single feature of C++ to get the job done, however use of those ignored features in other projects might make your life (and your code) much easier to handle.

Comments

Re:The one I keep running into: Polymorphism.

[StandardDeviant]

The Right Way to implement this is to make an abstract class for the tree node, write the tree manipulation methods to work with the abstract class, and make derived classes that store different types of data, with appropriate constructors that initialize the data fields. Anything that doesn't have to care about the data type can just manipulate the objects as the original abstract class.

This sounds like a perfect place to use the STL and/or C++'s templating mechanism. Trust me, I'm not a huge C++ fan, but the container classes in the STL kick ass (I imagine something like what you describe is already there). Even if the STL don't give you no lovin', templates (and references) make it really easy to write a storage class that works over an arbitrary range of types.

This is just my 2 cent's worth. I'm mainly a C guy too, but the STL was the single biggest thing tempting me to switch to C++.

There is good coverage of all this in Bruce Eckel's Thinking in C++ (and other such as the C++ Primer by Lajoie et al.) I mention Bruce Eckel's books because they're available to peruse online, his site is mindview.net which unfortunately seems to be down right now (maybe it's hosted in california ;-). I found a mirror of his C++ books in PDF form here and a mirror of all his books in HTML form here. If you're like me you'll read the book(s) online and end up liking them so much you want to own a paper copy (and here I make my standard reference to bookpool for discount tech books).

--
News for geeks in Austin: www.geekaustin.org

Coding practice

[ZeroConcept]

My experiences with a 2,000,000 lines of code C++ server project (in winNT):

1) ALLWAYS use SmartPointers unless you have a compelling reason to not use them.
2) Memory leaks are going to be your biggest problem, see rule number 1.
3) Use ASSERT like crazy...everywhere, if you are expecting some valid imput in a method, make sure it's explicilty stated with an ASSERT. ASSERT is the best way to catch an error on the spot.
4) Make the compiler generate debug symbols in release as a separate file, you WILL find bugs that only happen in RELEASE versions.
5) Use boundschecker to debug memory problems.
7) Don't use catch(...) on any other place than your main function...if you need to, rethrow the exception and let the debugger catch it. Never catch an exception that you don't know how to handle on the current scope.
6) Make your code exception safe, it's the only way to deal with memory exhaustion problems(http://www.relisoft.com/book/tech/5resour ce.html).
7) If you are using multiple threads and a large number of locks, use smartlocks, otherwise you will have deadlocks (it's painful but does pay off).
8) If you application is multithreaded, use a static locking order, otherwise you will have deadlocks.
9) NEVER, NEVER, NEVER create your own collections or strings, use STL.
10) If you use Visual C++ and STL, make sure you replace the source files with the fixed versions(http://www.dinkumware.com/vc_fixes.html).
11) Read "Effective C++" and "More effective C++" (look them up in amazon)
12) Avoid Runtime Type Identification, most of the times you don't need it.

send me a message at andresmurillo@go.com if you need more info.