Is it guaranteed by the standard that std::string will not give back allocated memory spontaneously if reassigned from a string of a smaller size?
In other words:
std::string str = "Some quite long string, which needs a lot of memory"; str = ""; str = "A new quite long but smaller string"; // Guaranteed to not result in a heap allocation? I ask because i'm depending on this to avoid heap fragmentation.
[string.cons]/36 defines assigning a const char* to an std::string in term of a move-assignment, whose definition is:
[string.cons]/32basic_string& operator=(basic_string&& str) noexcept(/*...*/)Effects: Move assigns as a sequence container, except that iterators, pointers and references may be invalidated.
This shows that the Committee let the implementation choose freely between an invalidating operation and a more conservative one. And to make things even clearer:
[basic.string]/4References, pointers, and iterators referring to the elements of a
basic_stringsequence may be invalidated by the following uses of that basic_string object:
- (4.1) as an argument to any standard library function taking a reference to non-const
basic_stringas an argument.- (4.2) Calling non-const member functions, except
operator[],at,data,front,back,begin,rbegin,end, andrend.
I ask because i'm depending on this to avoid heap fragmentation.
std::string takes as template-parameter an allocator. If you're really concerned by a possible heap fragmentation, you could write your own, which with some heuristics could have an allocation strategy suited for your needs.
In practice, most implementations I know of would not reallocate memory in the case of your question. This can be checked by testing and/or checking your implementation doc and eventually source code.
CPP reference states that assignment to a pointer-to-char
Replaces the contents with those of null-terminated character string pointed to by s as if by *this = basic_string(s), which involves a call to Traits::length(s).
This "as if" actually boils down to an rvalue assignment, so the following scenario is quite possible:
[string.cons]
x = "hi"; is the same as the effect of x.assign("hi");, an implementation would do the efficient thing for both. libstdc++, for instance, has its operator=(const CharT*) just directly call assignIs it guaranteed by the standard that std::string will not give back allocated memory spontaneously if reassigned from a string of a smaller size?
Regardless of the actual answer (which is "No, no guarantee") - you should employ the following principle: If it's not obvious that it has to be the case, then don't assume it is the case.
In your specific case - if you want tight control of heap behavior, you might not even want to use std::strings at all (maybe; it depends). And you might not want to use the default allocator (again, maybe); and you might want to memoize strings; etc. What you should absolutely do is make fewer assumptions, measure if possible, and have explicit design to ensure your needs are met.
If your strings are short (up to 15 or 22 bytes, depending on the compiler/std lib) and you are using a relatively recent compiler in C++11 or later mode, then you are likely to benefit from the Short String Optimization (SSO). In this case the string contents are not separately allocated on the heap.
This link also contains a lot of details on common implementations and allocation strategies.
However, both of the strings in your example are too long for SSO.
std::allocator<char>, but that can be changed) to allocate and deallocate memory, and the allocator may use a lower-level mechanism again (e.g. variants of operatorsnewanddelete) to actually allocate and deallocate. If any of those steps elect to not release memory to the lower-level layer, there is potential impact on heap fragmentation.