[pcwalton]

> Yes it does. That some compilers provide a way to disable mandatory language features is no argument.

It's actually very relevant that huge amounts of C++ deployed in the world use -fno-exceptions, and many shops (for example, Google!) have a policy of "we do not use exceptions". I don't care about how well languages handle OOM in theory; what matters is how well they handle it in practice.

[quotemstr]

> for example, Google!

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.

[pcwalton]

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.

[quotemstr]

> Certainly it reduces security vulnerabilities.

So does the power button. You can't get away with justifying breaking arbitrary functionality in the name of security.