question about memory management

[mrice]

Is there any internal garbage collection in the HDK?

For instance, in vex and python callback functions, do I need to delete every new object I create?

Like for a UT_String:

delete [] myString.steal()

[crunch]

Is there any internal garbage collection in the HDK?

For instance, in vex and python callback functions, do I need to delete every new object I create?

Like for a UT_String:

delete [] myString.steal()

If you call new, then you should call delete.

The destructor in UT_String will delete any memory it has allocated (as will other objects).

[mrice]

Thanks, what got me worried was in this thread:

Use IMG_File. First call open() to specify your image and then readImages() to parse specific image format data into a PXL_Raster. Don't forget to delete your PXL_Raster objects when done.

Why do you need to delete the PXL_Raster if it was allocated on the stack? But I guess that's so it doesnt sit in memory.

[edward]

Is there any internal garbage collection in the HDK?

There is no garbage collection in the HDK.

Offhand, I don't see anything contradictory between crunch's comment and my comment. If you called new, then you should generally call delete. There are exceptions to every rule of course.

Let's examine the IMG_File::readImages() interface. It looks something like this:

 bool readImages(UT_PtrArray<PXL_Raster *> &images, const char *scope = 0);

What you pass in is an array of PXL_Raster pointers. If you get non-NULL pointers back, then obviously readImages() allocated some PXL_Raster objects for you. Now the problem becomes who should delete such PXL_Raster objects. If you examine IMG_File, you'll notice that there are no corresponding deallocation functions. Therefore, you need delete them.

As crunch mentioned, UT_String will deallocate any memory it owns. The thing to note with UT_String objects is that they actually offer two different memory strategies. If you make them ALWAYS_DEEP, then they're roughly the same semantics as std::string. However, they use "copy-on-write" semantics by default. The copy-on-write semantics means that when you assign to a UT_String, it will only make a "shallow" copy (ie. only copy the memory address from the right hand side). This means that assigning to a such an UT_String is super fast since no memory allocation or copying occurs. The memory copy will only be made when you call some function in UT_String that modifies itself. UT_String always keeps track of the memory ownership so that its destructor knows when to deallocate the memory that it references.

There are three functions that allow fine grained control of memory ownership in copy-on-write UT_String objects. These are:

- harden(): Forces explicit ownership by making a "deep" copy of its memory

- adopt(): Takes ownership of the given memory

- steal(): [DANGEROUS] Returns a deep copy of the memory while giving away ownership. After calling steal(), it should never be used again.

UT_String str1, str2;
char raw[] = "abc";
str1 = raw; // only reference to raw
raw[0] = "X"; // str1 is now a pointer to "Xbc"
str1 += " world"; // makes copy and append " world" giving "Xbc world"
raw[0] = "a"; // does not affect str1 anymore
str2 = str1; // str2 references string owned by str1
str2.harden(); // force ownership: makes a copy of str1
str1.adopt(strdup("hello")); // takes ownership of the memory allocated by strdup(), old memory is deallocated

[mrice]

Thanks once again Edward, that's really helpful.