mjhjmtu

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.

No guarantee whatsoever.

[string.cons]/36 defines assigning a const char* to an std::string in term of a move-assignment, whose definition is:

[string.cons]/32

basic_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]/4

References, pointers, and iterators referring to the elements of a basic_­string sequence 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_­string as an argument.


• (4.2) Calling non-const member functions, except operator, at, data, front, back, begin, rbegin, end, and rend.

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:

1. A fresh temporary string is created.


2. 
   This string steals its contents as via assignment to an rvalue reference.

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?

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.