Things to do / not do in C++
Intro
As with pretty much all my brain-dump documents, this is just a public list of
things that I need to remind myself. No claims to guru-hood here :-)
- Don't call other constructors from inside constructors: it's undefined and unpleasant memory corruption of the created object ensues. For some reason no
g++ warning ensues.
- When constructing an interface for an object whose primary role is to store data in an STL container, keep true to the STL accessor methods — they are as they are for a reason!
- Interface methods should be public, internal methods should be protected, data members should always be private.
- Don't manipulate objects from the insides of other objects: returns by reference can be dangerous (the "Law of Demeter").
- Declare constness as often as possible: const variables, const arguments, const pointers. Member functions can and should be const if they don't change the object's data members.
- Respect "conceptual const".
- Pass method arguments by (const) reference if possible.
- Use the STL strings and containers rather than primitive strings and arrays.
- Delete operations on STL vectors will invalidate any active iterators: if you want to delete, use a list or deque.
- The best test for using mutable data members is "will the mutability make any difference to the user of the interface?". If "no", it's okay, otherwise don't do it.
- Build it in objects the first time round — retro-hacking global functions into object form is painful!
- Be aware of the stream manipulators, they're incredibly powerful and save you implementing your own hacky versions.
- General design rather than C++, but only the top-level function should write directly to output streams: pass a stringstream or similar to lower-level method calls.
- Don't include
using declarations in header files — they won't be scoped.
- Put
using namespace declarations in implementation (e.g. *.cpp) files freely, though!
- Use forward declarations rather than
#includes where possible: this can speed compilation enormously.
- Decide on a standard behaviour for the formatting of output streams from code blocks and functions and stick to it.
- Not just C++, but for variables that count numbers of things, use a prefix like "num" rather than "no".
- Use enums rather than strings as flags. Never use "magic numbers"!
- Learn about the Boost functionality and make use of it: things like
lexical_cast are enormously useful.
- Test things that should be logical truisms with the
assert() and Assert() macros.
- Use typedefs to maintain readability.
- More to come as I remember/encounter them!
And not a language tip but a practical one: make the error messages from your compiler (I'm using g++)
easier to read by using a coloriser and an STL error decryptor. My choices are colorgcc from
http://www.mindspring.com/~jamoyers/software/
and STLFilt from http://www.bdsoft.com/tools/stlfilt.html.
Super stuff. Make sure you run the STL filter before the coloriser or you'll probably end up with a mess!
That's all, folks
If you've got any comments, please address them to Andy Buckley via
www.insectnation.org.