Robustness and pointer safety in C++

Question

I'm currently building a server responsible of storing and managing few million records of fairly complex and interconnected data. For reasons beyond my control the work has to be done with C++.

I have my concerns about error handling and especially pointer safety. Dereferencing a null pointer can cause the entire server to crash whereas in some - perhaps more suitable - languages you would get a null pointer exception which you can then handle. So, basically, a bug in handling of some rare corner case of a rare operation can bring the whole service down instead of just making one particular request to fail. Bugs are impossible to avoid so how can I ensure availability and robustness in such an environment?

Answer 1

Use C++11 (e.g. with GCC 4.9.1), not some earlier standard. Read more about memory leaks, smart pointers, buffer overflow, memory corruption, RAII.

If you follow several coding guidelines, notably the rule of three (which in C++11 is actually a rule of five), you would be able to write robust code. Use smart pointer templates like std::shared_ptr, std::unique_ptr and use standard STL containers. You should almost never use raw pointers like SomeClass* and ::operator new (if you want to use them directly, you are probably wrong, and you should always initialize them, often to nullptr; I believe that every variable should be explicitly initialized -the compiler would optimize useless initializations-, because that makes program behavior more reproductible.).

C++11 is a difficult language. Take several weeks to read several books about it, notably by B.Stroutrup: Programming -- Principles and Practice Using C++, a Tour of C++, The C++ programming language.

Be aware that C++11 is a different language than C (and even than its predecessor C++98). You need to take time to learn it. Look also inside the source code of several recent free software projects coded in C++.

Compile with all warnings and debug info (g++ -Wall -Wextra -g). Improve your code till you got no warnings. Make an exhaustive test suite. Use valgrind (on systems where it is available). Perhaps consider using frameworks like Poco, Boost, Qt. On production machine, use a watchdog.

BTW, you might learn more about Garbage Collection (see also the GC handbook), and notice that C++ favors reference counting, which can be viewed as a simple and limited form of GC (which is unfriendly to circular references).

You could also use operating system specific things (for Linux, read Advanced Linux Programming and signal(7)...) to catch some runtime errors. (I'm not sure it is a good idea to catch SIGSEGV, you'll need some very system & processor specific code; but it is doable).

Also, you could perhaps generate some of your C++ code (see also this). My MELT system is doing so (and you might also customize GCC with MELT to add some additional coding rules checking).

You seems very concerned about null pointer dereferences. If that scares you so much (it should not, since it is actually an easy bug to find; memory leaks are harder to find), you might craft your own smart pointer (above existing facilities) which would raise an exception in that case.

BTW, robustness of your code is much more related to the code size and the care and effort put in developing and testing it, than to the amount of data or records it has to process: a well crafted 30KLOC software able to handle 1000 records would probably be able to handle many dozens of millions of records, if given enough resources (notably computer power, disk, and RAM). A few millions of records does not feel scary (consider using Sqlite or Postgresql or Mongodb, etc, etc....).

Notice that some people are able to write very robust C or C++ code; in particular, many free software database management systems (Sqlite, Postgresql, Mongodb) are coded in C or C++ and are able to run for years, managing terabytes -or perhaps petabytes- of data. If possible, make your software published as free software (and develop it in the open): you'll get useful feedback from outside.

Answer 2

A couple of auxiliary considerations (Basile got the important stuff):

1. pointer errors are always the result of coding errors.

   The symptom may be some unpredictable run-time crash, but the cause is contained, statically, in your code. It's entirely possible to write code that just doesn't contain these errors. The guidelines and books Basile mentions will make this easier, by teaching the right idioms and conventions.

   • since pointer errors are always the result of coding errors, languages which make them easy to survive just make it easy to write buggy code that doesn't actually crash. That may be fine if not crashing is the limit of your ambition, but doesn't make your code correct.

     IMO a better approach for programs that need to be robust is a language that makes it hard to write incorrect code. Of course C++ isn't that either, but null pointer exceptions aren't a step in the right direction.

2. if you need robustness, you should build it in at all levels.

   1. can you run multiple instances, so one failing won't take the others down?
   2. can you split tasks into stages which can be spread across processes for the same reason?
   3. can you journal/commit/rollback your changes cleanly? RAII-based commit/rollback works in the presence of exceptions (remember NPEs aren't the only unexpected event you should consider), and journalling can preserve changes across crashes/restarts.
   4. if you need to handle stray cosmic rays or other bit-flipping events (as per Vatine's comment), you need ECC memory. NPEs still don't help you here: the damage is just as likely to be in your code, or the kernel code, or some filesystem metadata, and even if by some great fortune the damage occurs to a pointer, it's much more likely to become a different (and possibly valid) non-null pointer.

---

For reference, I don't have anything against NPEs or the languages that provide them. They're good for adding resilience to non-critical code, and for allowing a useful degree of sloppiness in applications where development time is more important than correctness.

... in some - perhaps more suitable - languages you would get a null pointer exception which you can then handle.

This just indicates you'd like to write sloppy code and survive. While that's perfectly reasonably in some situations, that sloppy code is just as likely to silently and successfully produce garbage output as beautifully-handled NPEs.