0

So I see that there's pairings with memory management functions such as malloc/free, new/delete, and new[]/delete[], but sometimes you're not always calling new or new[] and you still have to call delete, delete[], or free. For example, strdup is one such function which encapsulates the allocation of memory and you'd still have to deallocate that memory yourself later on.

So when do you know to free memory, if you're not always writing new or malloc in some sense? I'm particularly curious about deleting arrays of objects. Just simple arrays. Because, that seems to be one of the use cases that delete[] is made for. (I'm looking at cplusplus.)

So, is this valid? Is this necessary? Is anything missing?

unsigned char bytes[4] = {0xDE, 0xAD, 0xBE, 0xEF};
for(int i = 0; i < 4; i++) 
    std::cout << std::hex << +bytes[i];
delete[] bytes;

bytes is technically an unsigned char * type, right? I know I technically have a pointer, but because this isn't an array of objects, I'm unsure whether or not it gets automatically destroyed.

  • You only need to `delete`/`delete[]` stuff that you have previously created with `new`/`new[]` – SingerOfTheFall Jun 05 '17 at 13:55
  • This is not necessarily true -- `strdup` can cause memory leaks if you don't delete. –  Jun 05 '17 at 13:57
  • 3
    `strdup` is non-standard, and you should `free()` the pointer it returns, not `delete` it, since it uses `malloc` internally. – SingerOfTheFall Jun 05 '17 at 13:58
  • 2
    *"So when do you know to free memory, if you're not always writing new or malloc in some sense? "* -- By looking at the documentation of the function. Note that the documentation of `_strdup` that you linked to says that it calls `malloc`, and it also explicitly tells you that the memory must be freed with `free()`. – Benjamin Lindley Jun 05 '17 at 14:11

2 Answers2

3

C++ when to use delete[] and properly deallocate memory?

When the memory was allocated memory with new[] and that memory has not yet been deallocated, and won't be deallocated by anyone else.

So, is this valid?

Not valid. What you've shown has undefined behaviour. You may not deallocate automatic variables. You may not call delete[] on anything that wasn't allocated with new[].

Is this necessary?

Not necessary. Automatic variables are destroyed... automatically, when they go out of scope.

bytes is technically an unsigned char * type, right?

I know I technically have a pointer

Not right. bytes is in all regards, an array. Not a pointer.

So is C++ different from C in that regard about pointers to arrays?

Not different. Arrays are arrays in C as well.

You may be confused with array decaying. When used in a value context, array name will decay into a pointer to first element. The pointer that the array decays into is a pointer, but the array is not. Example:

int  arr[4] = {1, 2, 3, 4}; // an array
int* ptr  = arr;            // a pointer; arr decays and is assignable to a pointer
int* ptr2 = &arr[0]         // decaying is syntactic sugar for this
int size1 = sizeof arr;     // size of the array == sizeof(int)*4
int size2 = sizeof ptr;     // size of the pointer == sizeof(int*)

Also, in a function argument list, array declaration is the same as a pointer declaration. Which is highly confusing. You just have to remember that arrays can not be passed by value, so an array as function argument must mean something else.

void foo(int[4]); // confusing
void foo(int*);   // actually means this
Community
  • 1
  • 1
eerorika
  • 232,697
  • 12
  • 197
  • 326
2

No, this is not valid.

Every single call to delete[] should be paired with new[]. If it doesn't pair up (e.g. strdup), it's because some function internally calls malloc/new[].

unsigned char bytes[4] = {0xDE, 0xAD, 0xBE, 0xEF}; declares 4 bytes of memory on the stack. Stack memory is automatically destroyed at the end of the enclosing scope. They share the same memory as those needed for function calls.

new/delete allocates and deallocates heap memory. Heap memory has no specific order of acquisition or destruction (unlike a stack, which is first-in-last-out), so you have to delete it explicitly or the program won't know when to deallocate it.

Bernard
  • 5,209
  • 1
  • 34
  • 64