Thread: Freeing memory on non-pointer variables

I just realized why don't we have to free memory (delete keyword) when we are dealing w/ non-pointer variables. I started thinking about this when I'm trying to build a hash table via linear probing and if load factor > 0.7 (I'm using wikipedia's credentials, not good but for practice), I would just declare a new array with twice the capacity. THen I thought what happens to the other array, once I'm done w/ it in terms of copying over all existing elems to the new array. Why don't we delete it. Even for something like:

Code:

int num_1 = 8;
int num_2 = 99;
int sum = num_1 + num_2;

cout << sum << endl;

//So now why don't we free memory occupied by variables: num_1, num_2, sum?? We do it all the time like with linked lists to link out a node we: delete node etc

my trivial linear probing implementation:

Code:

#include <iostream>

using namespace std;

int main()
{
  int ht_1[] = {};
  int ht_1_size = sizeof(ht_1)/sizeof(int);
 
  if ( load_factor(ht_1, ht_1_size) > 0.7 )
    int ht_2[ht_1_size * 2] = {};
  else
     linear_probing_insert(&ht[0], ht_1_size, 89);//try to insert 89 to hashtable

 return 0;
}

Again, I will look into using C++'s STL: array and vectors for static and dynamically allocated arrays, respectively. But for curiosity sakes. I'm guessing STL for those arrays take care of it for programmers esp in a career where we don't have to worry about memory management.

Code:

int ht_1[] = {};

O_o

I wouldn't take the time to discuss this for the "OP" because he doesn't pay attention, but I will explain it a little because you keep seeing his usage in broken code.

That is a simple extension to the common extension of "zero-sized arrays" used for expanded arrays in structures when used as the last element of an array.

Code:

struct STest
{
    int mSize;
    int mArray[];
};

This works in practice for a lot of standard reasons, but it is not itself part of the standard.

Even though it is an extension, it is ridiculously common with widely available semantics.

The secondary extension is almost exclusive to "GCC" where it continues to live for the sake of not breaking old code.

*shrug*

Not at all shockingly, he is still using it wrong even though it does probably compile for him.

Soma