Thread: Freeing memory on non-pointer variables

  1. #1
    Registered User
    Join Date
    Jul 2012

    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:

    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:
    #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] = {};
         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.

  2. #2
    Join Date
    Oct 2007
    Inside my computer
    For the sake of it,
    int ht_1[] = {};
    should not compile.

    Essentially, what you must learn is that there is the stack and the heap. Everything you put on the stack is popped at the end of the function (or more exact, at the end of the current scope). Therefore, ht_1 will be destroyed at the end of main. ht_2 will be destroyed at the end of the if statement.

    Btw, this
    int ht_2[ht_1_size * 2] = {};
    should not compile either because the size must be constant and ht_1_size is not constant.
    If you change
    int ht_1_size = sizeof(ht_1)/sizeof(int);
    const int ht_1_size = sizeof(ht_1)/sizeof(int);
    then it will compile, if you have a defined size on ht_1.

    >>linear_probing_insert(&ht[0], ht_1_size, 89);//try to insert 89 to hashtable
    This will not compile as ht does not exist. Even so, you should not do this since the arrays are local and will be destroyed at the end of the function. You will get problems later on.

    As for delete, when you use new, you must delete. new places the data on the heap and not the stack (and returns a pointer that must be stored on the stack). That you must delete.
    But don't concern yourself over that. Learn std::vector and std::array instead.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #3
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    int ht_1[] = {};

    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.

    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.


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


  4. #4
    Registered User
    Join Date
    Apr 2006
    The need to free dynamic memory has nothing to do with pointers. It's just that new returns a pointer, and delete returns a pointer. But you could convert the result of new into a reference if you wanted to (Don't do this).

    As Elysia says, stack variables do not have to be deleted because they are automatically deleted at the end of a the block they are in or the object containing them is destroyed. To make a heap variable do this, which you usually should, you need to put in in a smart pointer, like unique_ptr.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Dynamic memory and realloc(), freeing memory
    By C_Sparky in forum C Programming
    Replies: 6
    Last Post: 10-06-2010, 07:55 PM
  2. Issues with pointer and freeing its associated memory
    By tytelizgal in forum C Programming
    Replies: 10
    Last Post: 10-17-2008, 03:00 PM
  3. Freeing memory for non-pointer variables
    By SuperGodAntMan in forum C++ Programming
    Replies: 7
    Last Post: 02-11-2006, 01:30 AM
  4. freeing memory
    By mart_man00 in forum C Programming
    Replies: 1
    Last Post: 04-27-2003, 08:51 PM
  5. freeing memory..
    By tegwin in forum Windows Programming
    Replies: 13
    Last Post: 06-12-2002, 09:45 PM