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.
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.
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
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.
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.
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().
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.
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.
Related
As far as i know, std::string creates a ident array-copy of its content when you call the c_str()/data() methods (with/out terminating NUL-char, does not matter here). Anyway, does the object also take care of freeing this array or do I have to?
In short:
std::string hello("content");
const char* Ptr = hello.c_str();
// use it....
delete[] Ptr; //// really ???
I just want to be on the safe side when it comes to memory allocation.
No you don't need to deallocate the ptr pointer.
ptr points to a non modifyable string located somewhere to an internal location(actually this is implementation detail of the compilers).
Reference:
C++ documentation:
const char* c_str ( ) const;
Get C string equivalent
Generates a null-terminated sequence of characters (c-string) with the same content as the string object and returns it as a pointer to an array of characters.
A terminating null character is automatically appended.
The returned array points to an internal location with the required storage space for this sequence of characters plus its terminating null-character, but the values in this array should not be modified in the program and are only guaranteed to remain unchanged until the next call to a non-constant member function of the string object.
std::string handles this pointer so don't release it. Moreover, there are two limitations on using this pointer:
1. Don't modify string that is pointed by this pointer, it is read-only.
2. This pointer may become invalid after calling other std::string methods.
No need, the dtor of the string class will handle the destruction of the string so when 'hello' goes out of scope it is freed.
Not only you don't need to free the pointer but you in fact should not. Otherwise the destructor of std::string will attempt to free it again which may result in various errors depending on the platform.
The std::string class is responsible for freeing the memory allocated to contain the characters of the string when an object of the class is destructed. So if you do
delete[] Ptr;
before or after hello object is destructed (leaves the C++ {} scope it was created in), your program will run into a problem of trying to free a memory block that is already freed.
I have such class:
class Kot{
public:
string name;
};
I create an instance of it:
Kot* kot = new Kot;
kot->name = "John";
Then I want to create a duplicate of string:
string name;
name = strdup(kot->name.c_str());
I use strdup because I want to delete kot and use only name variable.
But I have a 5 bytes memory leak due tonamememory allocation.
How can I free it safely? I tried to dodelete &name`, but I have:
Process finished with exit code 134 (interrupted by signal 6: SIGABRT)
You probably detected a 5-byte memory leak, but it is not because of the string.
Each call to strdup creates a new char[] of the size matching the length of the string. You should bind it to a raw pointer char* and remove it at some point.
What you did instead, is that you create a temporary char* pointer. Let's call it temp for our purposes.
The temp string is then passed to std::string's constructor. The std::string makes another copy of it, leaving the original temp intact.
Then the temp pointer just dissapears, without properly clearing the memory.
At the end, when the std::string object is destroyed, it properly clears its own, private copy of the string. But the memory previously pointed by temp is never freed.
A quick fix would be to:
char* temp = strdup(kot->name.c_str());
name = temp;
free(temp);
However, you don't even have to do that! If you assign one std::string object to another, you make a proper copy of its contents already. So:
name = kot->name;
will most likely do exactly what you are trying to achieve already -- making a copy of kot->name within your name. In such scenario, name and kot->name become two completely separate strings with the same (copied) content. From that point onward, changing/deleting one does not affect the other.
You use free(), not delete.
Per the standard documentation:
The strdup() function shall return a pointer to a new string, which is
a duplicate of the string pointed to by s. The returned pointer can be
passed to free(). A null pointer is returned if the new string
cannot be created.
You have a memory leak here:
name = strdup(kot->name.c_str());
because you never release memory allocated by strdup.
To avoid this problem you can simply construct name from the kot->name:
name = kot->name;
In this Informit C++ guide, I read this:
Using malloc() to create a non–POD object causes undefined behavior:
//disastrous!
std::string *pstr =(std::string*)malloc(sizeof(std::string));
I didn't understand 2 points here :
Pointers are PODs. Then why it is called non-POD here? (Maybe I have to understand POD better.)
How can this be so disastrous? (I guess I have to understand string Internals for this.)
Please explain!
pointers are PODs then why here it is called non-POD
It's not talking about the pointer, but the std::string.
It's disastruous because malloc doesn't call the constructor, so you'll have pstr a std::string pointer that points to a std::string that wasn't properly constructed. The memory was allocated but it wasn't initialized properly, because of the missing constructor call.
The correct way is
std::string *pstr = new std::string;
The clean way is to just have a variable in automatic storage:
std::string str;
Here you are allocating a standard string, not allocating a pointer to a standard string. Note that you are passing sizeof(std::string) to malloc; that is how much memory you are getting back...note the size of the object is bigger than the size of a pointer. If you were only allocating a pointer, you'd expect the size passed in to be sizeof(std::string*).
The pointer you receive back is how you keep track of the result of the allocation, but that pointer isn't living on the heap. Here it's just being stored in an ordinary variable. Had you allocated a pointer instead, then your variable to keep track of it would need to be a pointer-to-a-pointer.
Anyway, if you wanted to, you could legally allocate a pointer to a standard string like this:
std::string str;
std::string** ptr_to_pstr = (std::string**)malloc(sizeof(std::string*);
*ptr_to_pstr = &str;
Why you would want to is not entirely clear. But neither is it clear why you'd use malloc in C++. :)
code 1 :
void foo(char * text) {}
foo("Test");
as far as i understand, this will happen :
memory is allocated for "Test"
pointer is created and its value is copyed to (char * text pointer), so (char * text) points to the place in memory, where "Test" is (better to say, on the first char of "Test")
after the function is done, it destroys the pointer(char * text), pointing to the beginning of "Test", doesnt create this a memory leak?
and the question is, when does the "Test" gets deleted, when the function destroys only the pointer
isn't it better to do smth. like that? :
char * _text = "Test";
foo(_text);
delete[] _text;
You can think of string literals as being part of the code. They aren't dynamically allocated, they have so-called "static storage duration", which means they exist for the duration of the program, and they don't need to be freed (indeed, must not be freed).
It is always wrong to delete[] something that wasn't created with new[], so your second code snippet has undefined behavior.
"Test" is a string literal, which has a static storage duration. It will not be deleted until the program works. And you should not delete it by yourself.
Actually it doesn't get deleted.
That string is allocated in data segment and the call to foo("Test") just pushes on the stack the pointer to that string, without "copying" it as you are saying.
It is not leaked memory because the string is part of the final binary file and it will always be there, in a section of the binary that is just for that kind of things (constants and so on).
It happens that the string itself (the bytes for "Test") are placed in data segment in a read-only section while the pointer (eg char *_test = "Test") is instead stored in a read-write section (stack or heap, it depends how the pointer is initialized and used). You are allowed to modify the pointer but that won't delete the string from the data segment.
Hard coded values in C are actually compiled into the binary and as such are not allocated. More correctly they appear in the "data" section of the executable and live as long as the program does.
Also, pointers are not "destroyed". Remember that pointers are just addresses to memory that may be anywhere (stack/heap) but pointers a not objects.
Code Segment 1:
wchar_t *aString()
{
wchar_t *str = new wchar[5];
wcscpy(str, "asdf\0");
return str;
}
wchar_t *value1 = aString();
Code Segment 2
wstring wstr = L"a value";
wchar_t *value = wstr.c_str();
If value from code segment 2 is not deleted then an memory leak does not occur. However, if value1 from code segment 1 is not deleted there is a memory leak. The internal code to wstring::c_str looks the same to me.
An important rule: you must use delete on anything that was created by new, and you mustn't delete anything else.
wstr.c_str() returns a pointer to a buffer that's managed by the wstring object. It will be deallocated when the string is destroyed, after which the pointer will no longer be valid. Using delete on this is wrong. The pointer will also be invalidated if you modify the string.
aString() returns a pointer to a buffer that was created using new[], so you must delete it when you've finished with it (using delete[], to match new[]). This is error-prone, which is why it is better practice to use resource-managing classes (like string, wstring, containers and smart pointers) rather than passing around raw pointers and hoping they are treated correctly.
Because c_str() returns you a pointer to the internal representation of the wstring. The class keeps control of the data it contains.
Taken from the basic_string::c_str() documentation from MSDN:
The returned C-style string should not
be modified, as this could invalidate
the pointer to the string, or deleted,
as the string has a limited lifetime
and is owned by the class string.
I'm going to go out on a limb and say that a wstring is not a wchar_t, but instead a class that has an operator to return a wchar_t *, so in the destructor of wstring, it likely frees its own copy of the wchar_t * it returns.