Wrong. I WOULD NOT advocate the use of templates just because I use C++. But I WOULD advocate using safe language features and compile-time type checking. Throwing pointers around is bad practice, hence C++'s encouragement to use references, move semantics and emphasis on use of containers, clear tidy-up practices, obvious demarkation of what owns an object, RAII etc. This moves the burden onto the compiler, not the developer or team of developers to understand where data is owned, when it will be cleaned up etc. etc.

Further, templates do not make C++ slow; it is simply compile-time polymorphism.

Does runtime polymorphism make software slow? Does casting to or from a void* in C suddenly make it slow? The entire emphasis in C++ for templates is that you pass the error checking to the compiler, not at runtime to guess that this incoming void* is the type that you want. reinterpret_cast is only used where absolutely necessary!! It is far safer to NOT cast. Avoid casting. Templates (and the STL) help out in this regard.

I would use the STL for projects, and encourage every else in C++ land to do the same. Containers make sense, as do the algorithms associated with them (and they save you reinventing the wheel).

But I would NOT advocate use of Boost just because it is popular or written in C++. That would be a stupid reason to encourage its use; I personally do not use Boost. Boost != STL. You appear to be confusing Boost with the STL ??

No doubt your unbridled hatred of C++ and libraries written in C++ (eg. Boost) has stopped you reading reference works on the STL. You can find a comprehensive reference here: http://en.cppreference.com/w/

There's no Boost on there, btw. That's at boost.org.

Personally, I was only making the comment regarding a reminder of my own coding style in light of the problems they found in their C codebase. I do not write C, but I can see that the pitfalls they fell into could easily be carried out by me in C++ if I stuck to unsafe coding styles.

Furthermore, many of their problems could be solved in C++ land very easily: NULL pointer dereferences (don't use pointers, use references - it'll never be NULL), Invalid pointer arithmetic leading to SIGSEGV due to unmapped memory access (use STL containers), Out-of-bounds reads and writes to stack, heap and static-based arrays (use STL containers, you may still get out-of-bounds problems but at least an exception is thrown), Invalid free() calls, Double free() calls over the same pointer (use move semantics, never see a new or delete ever again), Division errors (use a static_assert to check that a value is in range, if possible. Or use an assert in a defensive coding style), Assertion failures (use static_assert to catch at compile time if possible), Use of uninitialized memory (RAII - initialise before use).

Your (or anyone's) invalid use of C++ does not make the language invalid, in the same way that stabbing someone with a knife does not suddenly mean all knives must be banned.