I work for corporation that is pretty pragmatic about these things. We like to use the newest toys that modern c++ gives us, but since we need to support older versions of macOS, we are limited by what we can use for the lowest supported deployment target. Given that: Until very recently we used c++17, but with a set of standard library features that was off-limits. Examples of these are things like std::variant (because std::bad_variant_access requires 10.14), std::filesystem (requires 10.15 for std::filesystem_error). We've recently started using c++20, which works fine for all the language features - even if not all the library features are supported. In short: What I tihnk is relevant is is which library features you depend on. Compilers are easily updated, without much risk, but if you depend on library features with a compiled component, you'd need to be aware of which OS-version supports it. macOS is usually the lowest common denominator in this. On Sun, 2022-07-24 at 10:09 -0700, Vinnie Falco via Boost-users wrote:
I'm considering bumping up the C++ language requirement for Boost.URL from C++11 to C++14. I have concerns about doing this, because it affects all my downstream libraries (HTTP.Proto, HTTP.IO, Websocket.Proto, Websocket.IO, and any examples or complete clients/servers that I write).
My main fear is that there are still a considerable number of individuals or corporations who, for whatever reason, cannot build with -std=c++14 or later despite having access to newer compilers. I don't mind if there is a small percentage of loss but I do mind if 20% or more of potential users will be locked out.
The questions are:
1. Would you or your company be prevented from using Boost.URL if it required C++14?
2. Do you know any other organizations who cannot use C++14 or later?
3. Do you know of any regional or global metrics on who _cannot_ use libraries which require C++14?
See also, this reddit thread on r/cpp:
https://www.reddit.com/r/cpp/comments/w6zuo5/c11_or_require_c14/