Even if not inlined at -O0, when instantiated for a custom some_type, the standard library .so won't contain any code for it, everything will be in the application binary.

Depends on the implementation of helper functions and if external templates are being used.

extern templates won't help for user defined types of course as the standard library couldn't possibly have instantiations for them :).

Some non template helpers might be improved of course.

They help for common types like std::string.

On Windows it can still live on a dynamic library.

That has been a thing since the Windows 16 bit days, and other OSes with similar linking models like Symbian, OS/2 and AIX.

It’s difficult to imagine which applications would find the performance of an outline vector access acceptable. Generally vector::operator[] is represented in built programs by a single x86 mov. A call would wreck the performance. In languages with bounds-checked vectors, they don’t do it with library calls.

I have practically always used bounds checked vectors and strings.

In the old days, all C++ frameworks bundled with compilers tended to have bounds checking enabled by default (Turbo Vision, OWL, VCL, MFC, PowerPlant, CSet++, Qt,...).

Nowadays I always set _ITERATOR_DEBUG_LEVEL to 1 on VC++, unless I am not allowed to.

Mostly the performance problems that were dealt with, had to do with badly chosen algorithms and data structures.

Modern Android ships with FORTIFY enabled.

https://android-developers.googleblog.com/2017/04/fortify-in...