About 18 months ago, I ported a project I was working on from C to C++. I, too, wanted a few C++ features to simplify life, mainly to use the STL, but also for inheritance in a handful of places. I got what I wanted, but I have since concluded that switch to C++ was, on the whole, a mistake.
First, don't discount the longer compilation times. After learning Lisp, I became rather addicted to the rapid turn-around time of compiling code at the level of individual functions. I can tolerate C because, with a relatively clean build setup, it compiles quickly. g++ on my project is between 10 and 20 times slower than gcc. This means that, as I make minor changes, I'm more likely to have to wait a while for a build to finish. This means I'm more likely to slack off in between builds. This kills (my) productivity horribly.
Second, auxiliary tool support on Unix leaves a lot to be desired. I sprinkle my code with templates in places where they promote readability, and I use STL containers. gdb, at least the version I'm using, does not support displaying data in STL containers. This means that when I have to track down a problem with data in a map, gdb can't help me. I have run into nasty problems for which I had to write custom print-this-templated-structure-to-log code. In addition, g++ error messages which involve templates absolutely suck. Luckily, I can quickly figure out what I need to change just by looking at the affected line.
After thinking through these issues, I concluded that C++ wasted more of my time than it saved. YMMV, of course.
If minor changes trigger long compilation, there is something wrong with your code organization. I found that if you count linking time the total build time difference between c and c++ for significant project is not that big at least not at 10-20x.
There are plenty of gdb macros that support stl containers even 18 months ago.
If minor changes trigger long compilation, there is something wrong with your code organization
A lot of larger C++ projects use "pimpl" for this reason (http://en.wikipedia.org/wiki/Opaque_pointer). Also in professional projects with large code bases that I've worked on in the past we've always had a distributed compilation environment (distcc, icecream, etc.)
I tried some of those gdb macros, but they did not work for me. Don't remember the details. In any case, in a recent debugging session, I noticed that gdb elides or loses some essential iterator features. For example, iterator->first and ->second do not show up if I execute the "p" command in gdb. The whole situation led me to claim that, at least in open-source Unixland, the C++ toolchain leaves a great deal to be desired.
I'm as disappointed by gdb's C++ support as anyone, but is it really fair to complain about its lack of support for STL containers? C doesn't have _any_ containers, so there's nothing there for gdb to lack. Either way you have to printf debug, though I can see how the increased compile times make that more tedious.
First, don't discount the longer compilation times. After learning Lisp, I became rather addicted to the rapid turn-around time of compiling code at the level of individual functions. I can tolerate C because, with a relatively clean build setup, it compiles quickly. g++ on my project is between 10 and 20 times slower than gcc. This means that, as I make minor changes, I'm more likely to have to wait a while for a build to finish. This means I'm more likely to slack off in between builds. This kills (my) productivity horribly.
Second, auxiliary tool support on Unix leaves a lot to be desired. I sprinkle my code with templates in places where they promote readability, and I use STL containers. gdb, at least the version I'm using, does not support displaying data in STL containers. This means that when I have to track down a problem with data in a map, gdb can't help me. I have run into nasty problems for which I had to write custom print-this-templated-structure-to-log code. In addition, g++ error messages which involve templates absolutely suck. Luckily, I can quickly figure out what I need to change just by looking at the affected line.
After thinking through these issues, I concluded that C++ wasted more of my time than it saved. YMMV, of course.