Any dynamic allocation, but especially allocation of variable size representations, creates endless complications deep inside any long running program.
Georges Khalil cautions on a developer list, std::string is responsible for almost half of all allocations in the Chrome browser process; please be careful how you use it! post 
The ensuing discussion drifts in and out of obscure jargon. Developers remind each other whether the concern is for the space that is allocated or the time it takes to allocate and reclaim it. This conversation has roots in the 50's.
Quote Khalil
StringPrintF and its variants make a lot of temporary allocations and are not a good use for string concatenation. We ran a test pitting StringPrintf against append for string concatenation and found the latter 2.5x to 3x faster. This is not surprising when analyzing base/strings/stringprintf.cc
A lot of times, a std::string is being passed as a const char* (using c_str()), only to be converted back to std::string. Using base::StringPiece or passing a const ref to a std::string all the way is much more efficient
When dealing with a vector/string, memory reservation is not always used, which increases the number of allocations during insertions
.
I'm reminded of the technobabble required to describe the hunt for gravity waves in Commissioning Story. Similar except this isn't some exotic research instrument, it is the browser we use all day long. These developer's success determines how we will talk in our own future.
I've argued On Numbers that we are too quick to squeeze variable size numbers into fixed sized representations. Here the hyper-variable size and lifetime of strings demand relentless caution wielding them as values.