A mostly C codebase using a bit of STL will almost certainly not use exceptions. So there's no need to worry about exception safety.

The STL can throw exceptions, but it's easy to avoid that if you use the right patterns (i.e., find() instead of at(), iterators, and so on). If you build your C code as C++, exceptions will flow through it just fine. Nothing will throw anything unless call throw (or you run out of memory).

> If you build your C code as C++, exceptions will flow through it just fine.

Exceptions will propagate up the stack, but won't clean up resources since the C code expects to do that manually. Same is true for non-RAII C++ code that is not written to expect exceptions.

Your main point is correct though: Large parts of the C++ stdlib do not throw.

Well, you could compile everything with noexcept and not use exceptions, but that would certainly make large chunks of the STL useless.

What? Everything in the STL works fine without exceptions. Only wrinkle is if one wants to handle out of memory in way besides crashing, although there is generally nothing better to do. Besides, the kernel will often kill processes rather than return malloc failures (see the OOM killer) anyway.

IIRC, STL constructors throw if they can’t run successfully. I suppose if you’re sure that OOM is the only thing that is going to cause constructors to fail, you can just live with allocation failures causing program termination.