Even if bounds checks were only active in debug builds, that would already be of high value.
In MSVC or Clang, when compiled against the Microsoft C++ STL, they already are. So,
auto x = std::vector{1, 2, 3, 4, 5};
std::println("{}", x[5]);
In fact on Windows, even the C runtime has debug checks. That's why there are four options to choose from when linking against the modern UCRT:
/MT (static linking, no debug)
/MTd (static linking, with debug)
/MD (dynamic linking, no debug)
/MDd (dynamic linking, with debug)
It mostly impacts templated code, so it's a compiler flag, not a linker flag. Many distributions have been using this flag to build C++ code for quite some time.
(And this concerns GNU libstdc++, not glibc, so different licensing rules apply.)
Also, I mentioned no libc equivalent, and that remains true. Regardless of the libc distribution (glibc, musl, BSD, macOS libSystem), none of them have a debug mode in the vein that Windows UCRT does.
First in compiler vendors frameworks, pre C++98, afterwards with build settings.
It is quite telling from existing community culture, that some folks only read their compiler manuals when government knocks on the door.
What do you want to say?
Is this bad? I think this is desired. Only in c or c++ world people act like understanding how compiler internals work (often poorly) is desired
One does not need to understand compiler internals to be aware what build flags are used to turn bounds checking on the standard library.
I think this says more about other parts of the developer ecosystem than about C and C++. Understanding how the compilers work (and how CPUs work) is fundamental to software development.
Well, you can get very, very far without understanding compiler passes and how CPUs work