Well, that's horrifying. Presumably the value is being copied whenever it is converted from a const char * to a std::string?
The right thing (TM) would probably be to refactor some of the std::string's into std::string_view's, for instance by adding overloads where it makes sense. I doubt you could avoid all the copies, but I think you could cut it down substantially if you collected metrics and focused on the most egregious cases.
Of course, I do not envy the person who is tasked with doing that, and I could be wrong for any number of arcane technical reasons.
I can only imagine that using std::string_view in a massive, complex application would be horrifying.
The borrow checker is one of the benefits of Rust in that case, simply because you can avoid copies while actually being able to trust that you're not opening the door to security & maintenance hell in the process.
Fun fact: this happened during the standardization of std::string_view, which ended up landing in C++17, a few years after this was fixed. Not that there weren't non-standard versions that existed.
In the end they did a number of things to fix this, the patches are linked in the story I linked above.
std::string_view has seemed, to this relative outsider, to be semi-controversial. It makes it pretty easy to introduce use after frees, that it's not null terminated can be easy to forget, and isn't bounds checked. So while it helps with some issues, it can create others, meaning it's not always a clear win.
The right thing (TM) would probably be to refactor some of the std::string's into std::string_view's, for instance by adding overloads where it makes sense. I doubt you could avoid all the copies, but I think you could cut it down substantially if you collected metrics and focused on the most egregious cases.
Of course, I do not envy the person who is tasked with doing that, and I could be wrong for any number of arcane technical reasons.