string.c_str() deallocation necessary?
Solution 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 ASCIIZ 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 insides
, which will be stack- or statically-allocated as explained fors2
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, ands2
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...
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 whichc_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.
Solution 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.
http://www.cplusplus.com/reference/string/string/c_str/
(Edited for clarity based on comments below)