This is quite a neat trick. Consider:

#include <cstdlib>

int main(int argc, char** argv) {
  int* ptr = NULL;
  *ptr = 1;

  exit(EXIT_SUCCESS);
}

Referencing that NULL pointer obviously crashes straight away with a terse segmentation fault:

By simply linking it with libSegFault, which seems to be documented only very informally, but comes with glibc:

Of course you could get all this by starting the program with gdb but this looks like a great technique for diagnosing crashes “in the wild”. Not that my code segfaults all the time, mind! After writing this, I found some more details on Stack Overflow, including a good tip about c++filt. Another useful utility is addr2line.

Also I am starting to incorporate libtap++, an implementation of the Test Anything Protocol, into my projects. C++ has strong typing, at least stronger than plain C, which helps trap errors at compile time like in OCaml. But since I always write a test harness anyway, it makes sense to fall into line with the way everyone else does it, especially as I have ambitions for wider adoption of my bindings†. Presently there is no TAP producer for OCaml‡, so at some point I will work on that too (or just bind to the C libtap).

On the recommendation of a friend of mine who is a very experienced C++ programmer, I have been playing with Eclipse CDT, which is pretty nice for C/C++ but doesn’t deal well at all with mixed C++/OCaml projects, and EclipseFP seems to have dropped support for OCaml at some point. I think I’ll try using it for just the .so portion of my projects and stick with Emacs/make for final integration with OCaml bindings, at least until I see if it really is more productive to do C++ in a full-blown IDE versus good old Emacs. Also I’ve bought a copy of The Boost C++ Libraries, again on the recommendation of my friend, that whatever I want, it’s probably already in Boost.

† OPERATION FOOTHOLD
‡ See comments