Compilers removing security features: Optimization-unstable code

You are literally four keystrokes away from a compliant version, bitch.

As I mentioned, I'm fully aware that most C++ programmers don't see the creation of a worthless temporary as a problem. But C programmers see you putting a struct on stack, initializing several fields, then passing a pointer to that struct purely to work around the awkwardness of your language and not any sort of programming problem as an example of why C++ is shit.
It must be nice to not work on anything of any importance where compatibility matters.
Again, I don't see string_view as viable due to the reasons I listed earlier. I primarily write C++ code and we gave up on C++ strings a long time ago.
This isn't really "C++ strings". It also has horrible performance problems, at least as of a year or two ago, and suffered from the variadic template explosion problem you might have seen me mention in other threads if you're a Holla Forums regular. The concept isn't bad though, and I have my own implementation that performs closer to the better mprintfs.
This is pure streetshitting. You're adding restrictions purely because you have a problem using your tools, not because the restrictions were desired. Don't do this.
No, as no one uses any of the wide character support in C. That's different in C++ where people expect to abuse standard library containers for their own types. You should never use wide character support in C++ either, though.

That's bad code, it's right to remove it. The problem is you have two statements that have an invisible requirement between them yet could appear at any distance from one another in a program. It's very fragile and is just a matter of time until some programmer making a change converts safe code into unsafe code. In your case, it often happens during localization - some programmer changes "none" to _("none") and then some translator triggers the bug in a language where a name of none is translated as a phase.
snprintf() would be fine in that situation as it would fail gracefully. Hopefully there's not a policy where you work to not use it. Never use strncpy() or strlcpy(), though.

What's wrong with strlcpy?

It's not standardized and on many platforms will have no maintainer. You can get the same behavior from snprintf, standardized.

Microsoft have their own compiler, MSVC Compiler, they are the ones who ultimately programmed the compiler to optimize the code. It doesn't matter what balances you make, the fact is Microsoft caused the problem.

The bigger faggots are the ones who think strncpy automatically makes everything safe.

What? You're supposed to pass string_view by copy. It's no more costly (and slightly less error-prone) than separately passing pointer and size arguments. Having a parameter that's a pointer/reference to a string_view would be pointless.
Since C++98 code can't assume std::string is contiguous, it should be possible to add code which does assume that and just compile with a C++11 compiler. Unless what you want is actually some kind of retrofitted forward compatibility, which pretty damn retarded.
Your reasoning is weak.
No, but it's a C++ replacement for sprintf, as you ask. And one that has been proposed for addition into the standard library.
No, not really: github.com/fmtlib/fmt#benchmarks
Absolutely not. The variadic template function is just a thin wrapper (easily inlined); the arguments get stored in a type-erased container.
I can't believe a C programmer would be uncomfortable with the idea of a function requiring the caller to enforce restrictions on data passed to it. And the "don't put null terminators in the middle of the string" restriction should make you feel at home, too :^)

so what you are saying is that gcc and clang dont optimize away ZeroMemory?
do you know about memset_s? is this also microsofts fault?

They also optimize it. Blame society if you want, Microsoft is the one to make it and say ok.