Is string.c_str() deallocation necessary?

Question

My code converts C++ strings to C strings somewhat often, and I am wondering if the original string is allocated on the stack. Will the C string be allocated on the stack as well? For instance:

string s = "Hello, World!";
char* s2 = s.c_str();

Will s2 be allocated on the stack, or in the heap? In other words, will I need to delete s2?

Conversely, if I have this code:

string s = new string("Hello, mr. heap...");
char* s2 = s.c_str();

Will s2 now be on the heap, as its origin was on the heap?

To clarify, when I ask if s2 is on the heap, I know that the pointer is on the stack. I'm asking if what it points to will be on the heap or the stack.

Answer 1

string s = "Hello world";
char* s2 = s.c_str();

Will s2 be allocated on the stack, or in the heap? In other words... Will I need to delete s2?

No, don't delete s2!

s2 is on the stack if the above code is inside a function; if the code's at global or namespace scope then s2 will be in some statically-allocated dynamically-initialised data segment. Either way, it is a pointer to a character (which in this case happens to be the first 'H' character in the null-terminated string_ representation of the text content of s). That text itself is wherever the s object felt like constructing that representation. Implementations are allowed to do that however they like, but the crucial implementation choice for std::string is whether it provides a "short-string optimisation" that allows very short strings to be embedded directly in the s object and whether "Hello world" is short enough to benefit from that optimisation:

• if so, then s2 would point to memory inside s, which will be stack- or statically-allocated as explained for s2 above
• otherwise, inside s there would be a pointer to dynamically allocated (free-store / heap) memory wherein the "Hello world\0" content whose address is returned by .c_str() would appear, and s2 would be a copy of that pointer value.

Note that c_str() is const, so for your code to compile you need to change to const char* s2 = ....

You must notdelete s2. The data to which s2 points is still owned and managed by the s object, will be invalidated by any call to non-const methods of s or by s going out of scope.

string s = new string("Hello, mr. heap...");
char* s2 = s.c_str();

Will s2 now be on the heap, as its origin was on the heap?

This code doesn't compile, as s is not a pointer and a string doesn't have a constructor like string(std::string*). You could change it to either:

string* s = new string("Hello, mr. heap...");

...or...

string s = *new string("Hello, mr. heap...");

The latter creates a memory leak and serves no useful purpose, so let's assume the former. Then:

char* s2 = s.c_str();

...needs to become...

const char* s2 = s->c_str();

Will s2 now be on the heap, as its origin was on the heap?

Yes. In all the scenarios, specifically if s itself is on the heap, then:

• even if there's a short string optimisation buffer inside s to which c_str() yields a pointer, it must be on the heap, otherwise
• if s uses a pointer to further memory to store the text, that memory will also be allocated from the heap.

But again, even knowing for sure that s2 points to heap-allocated memory, your code does not need to deallocate that memory - it will be done automatically when s is deleted:

string* s = new string("Hello, mr. heap...");
const char* s2 = s->c_str();
// <...use s2 for something...>
delete s;   // "destruct" s and deallocate the heap used for it...

Of course, it's usually better just to use string s("xyz"); unless you need a lifetime beyond the local scope, and a std::unique_ptr<std::string> or std::shared_ptr<std::string> otherwise.

Answer 2

c_str() returns a pointer to an internal buffer in the string object. You don't ever free()/delete it.

It is only valid as long as the string it points into is in scope. In addition, if you call a non-const method of the string object, it is no longer guaranteed to be valid.

See std::string::c_str

Answer 3

Firstly, even your original string is not allocated on the stack, as you seem to believe. At least not entirely. If your string s is declared as a local variable, only the string object itself is "allocated on the stack". The controlled sequence of that string object is allocated somewhere else. You are not supposed to know where it is allocated, but in most cases it is allocated on the heap. I.e. the actual string "Hello world" stored by s in your first example is generally allocated on the heap, regardless of where you declare your s.

Secondly, about c_str().

In the original specification of C++ (C++98) c_str generally returned a pointer to an independent buffer allocated somewhere. Again, you are not supposed to know where it is allocated, but in general case it was supposed to be allocated on the heap. Most implementations of std::string made sure that their controlled sequence was always zero-terminated, so their c_str returned a direct pointer to the controlled sequence.

In the new specification of C++ (C++11) it is now required that c_str returns a direct pointer to the controlled sequence.

In other words, in general case the result of c_str will point to a heap-allocated memory even for local std::string objects. Your first example is not duifferent from your second example in that regard. However, in any case the memory pointed by c_str() is not owned by you. You are not supposed to deallocate it. You are not supposed to even know where it is allocated.

Answer 4

std::string::c_str() returns a const char*, not a char *. That's a pretty good indication that you don't need to free it. Memory is managed by the instance (see some details in this link, for example), so it's only valid while the string instance is valid.

Answer 5

s2 will be valid as long as s remains in scope. It's a pointer to memory that s owns. See e.g. this MSDN documentation: "the string has a limited lifetime and is owned by the class string."

If you want to use std::string inside a function as a factory for string manipulation, and then return C-style strings, you must allocate heap storage for the return value. Get space using malloc or new, and then copy the contents of s.c_str().

Answer 6

Will s2 be allocated on the stack, or in the heap?

Could be in either. For example, if the std::string class does small string optimization, the data will reside on the stack if its size is below the SSO threshold, and on the heap otherwise. (And this is all assuming the std::string object itself is on the stack.)

Will I need to delete s2?

No, the character array object returned by c_str is owned by the string object.

Will s2 now be on the heap, as its origin was on the heap?

In this case the data will likely reside in the heap anyway, even when doing SSO. But there's rarely a reason to dynamically allocate a std::string object.

Answer 7

That depends. If I remember correctly, CString makes a copy of the input string, so no, you wouldn't need to have any special heap allocation routines.