I very much doubt most people coding in C++ would turn off exceptions. Virtually every new runtime construct being added is designed for exceptions.

There are some niches where exceptions are frowned upon, but those are small.

Unfortunately a significant portion of feedback for the C++ standard library comes from Google LLC

Define most here a little bit more. I would imaging most people using it are hobbyists/students and, in that case, I think you're right.

But most people using it in industry fall into two camps:

1. using it because the project is old enough that C++ was a reasonable default when the project started. You may also be right here

2. using it because performance is absolutely critical to the application, here I would actually imagine you're wrong. noexcept removes a ton of stack-unwinding code, and you can absolutely get a significant performance boost out of it. It would be weird if they didn't pull this lever, given the perf boost and that errors as values is also a fairly reasonable way to handle problem

In the second category, google famously had a "no exceptions" rule at one point (could still be in effect, I have no knowlegde of google)

The latest version the Google C++ Style Guide of says: "We do not use C++ exceptions."

Ref: https://google.github.io/styleguide/cppguide.html#Exceptions

They do have that rule, but not for performance reasons. The full decision is here https://google.github.io/styleguide/cppguide.html#Exceptions and probably worth a read but the two main take away I think is:

> Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions.

I see noexcept as a part of the language that works together with exceptions, it is a valid optimization for certain (typically small) pieces of a code base that otherwise uses exceptions.

I'd imagine when people say "not using exceptions", it is about using compiler flags to completely disable the exception mechanisms from the language. And this also invalidates many of the design patterns C++ is known and sometimes praised for, at least RAII and operator overloading.

ABI compatibility is needed in 99% of the cases since you basically never compile your own STL. You dynamically (or statically if you will) link against the one you have on a system since most software does not have a control over the machines/environment where it's going to be deployed. Even in cases where you do have a control over your environment deployment, compiling your own libc++/libstdc++ is a complication which you usually want to avoid.

The C++ standard library is about 90% template code in headers. Yes, you compile it all the time, in your own environment. You have no choice.

The fact that you will use a class or function template from STL, and compile it, doesn't change the fact that, regardless of that, you will have to link against the libstdc++ or libc++ which you didn't compile yourself. I am not sure I understand the argument you're trying to make.