The String Class

[ForTheReallys]

Alright so I've been programming in C++ for almost a year now. And I've decided to learn how to use a debugger. So after learning the basics of debugging, I decided to learn how the string class works and how it allocates and deallocates memory. In doing this I wrote the following C++ program

#include <iostream>

using namespace std;

void func()
{
    string var = "BBBB";
    var += "CCCC";
}

int main()
{
    string one = "Hello";
    func();
    one += " + 1";
    one += " + 2";
    one += " + 3";
    //etc
}

Now when I debug this program using gdb, I can see that the string is a pointer to a address which holds the string. Now when the operator '+=' is used, the string pointer points to another address and copies its contents and appends the last string. Now what I thought was weird, was that when I looked at the last address that string was pointing to, the first string was still there. For example, [code]one += " + 1"; actually is stored in a new address while the original value of one is still stored in the previous address. Now what I don't understand is why the string class doesn't delete the object in the old address.
Even after the function call returns, the "BBBB" string is still located in memory. Why does the string class leave garbage in the heap? Is this a bug?

[firedraco]

Just because BBBB still exists in memory doesn't mean it hasn't been deleted. See: http://stackoverflow.com/questions/6441218/can-a-local-variables-memory-be-accessed-outside-its-scope/6445794#6445794

This isn't the exact same situation but the reasons behind it are the same.

[ForTheReallys]

Oh OK I understand now. Thanks!

[ForTheReallys]

OK so I tested it out by trying to allocate another string variable in a different function assuming it would point to the same address because it was freed. However that is not what happened. It pointed to another address and not back to the original address of "BBBB". Even when the size is the same. Does this mean there is a small memory leak in the string class?

[dhayden]

Does this mean there is a small memory leak in the string class?
No. It just means that the memory allocator works differently from your assumption. That doesn't mean it's wrong.

Or to put this another way, where in the standard does it say that a new string should go in the same place as an old string of the same size? The answer of course is that it doesn't.

Be careful here. As you examine the way string works (on your system, with your specific version of your specific compiler), don't assume that the string works a particular way always. The only thing that an implementation is required to do is what's specified in the standard.

When you make an assumption about how the implemtation works, you actually introducing a bug in your code. If you upgrade your compiler to a version that does things slightly differently, suddenly your code might not work anymore.

A bit of history: this problem plagued Microsoft in early versions of DOS. The documentation wasn't very good and people would make assumptions about the OS based on how it behaved. When MS created a new version, all sorts of software would break. Apple had the same problem in MacOS. They once created a new memory allocator that was 50 times faster than the old one. Only when they tried to use it, lots of programs crashed. It turned out that programs assumed, probably without their authors realizing it, that the contents of freed memory was unchanged until the next call to the allocator.

[ForTheReallys]

Ok I see. Thanks!!!