Google's C++ coding standards have done tremendous harm to the C++ community by perpetuating obsolete programming practices like two-phase initialization and lossy error reporting. Google's C++ standards also teach people that it's okay to use the STL and not worry about allocation failure, which hurts program robustness generally.
I think it's hard to argue that Google is in the wrong by not wanting to rely on std::bad_alloc for dealing with OOM.
> Google's C++ standards also teach people that it's okay to use the STL and not worry about allocation failure, which hurts program robustness generally.
Actually, I think making std::bad_alloc call std::terminate improves program robustness by a lot over trying to gracefully recover from all allocation failure. Certainly it reduces security vulnerabilities.
Google's C++ coding standards have done tremendous harm to the C++ community by perpetuating obsolete programming practices like two-phase initialization and lossy error reporting. Google's C++ standards also teach people that it's okay to use the STL and not worry about allocation failure, which hurts program robustness generally.
I'm not the only one who thinks so: see https://www.linkedin.com/pulse/20140503193653-3046051-why-go...
My C++ code is exceptional, modern, and robust, and anyone using -fno-exceptions can go fly a kite.