No Variables But Pointers

[jasonrobertz357]

Is it bad that instead of a program which has a variables and pointers, all it has are pointers, no variables. Why am I doing this? Just because with pointers, if you are done with the data, you could just free it's memory (This is what I currently know including that the less memory you use, the faster the program is. Please inform me if I'm wrong ^_^).

[MiiNiPaa]

the less memory you use, the faster the program is

False. Heap memory are usually allocated and freed slower than stack. Also unless you program is swapped, used memory will not slow down your program. Dereferencing pointers, on the other hand, will. Pointers uses memory for itself too.

with pointers, if you are done with the data, you could just free it's memory

When stack variable goes out of scope it will be destroyed.

Stack example:

int main()
{
    int y = 0;
    {
        int temp; // set aside 4 (in my case) bytes (pobably one instruction: increasing stack pointer)
        while(std::cin >> temp)
            y += temp;
    } //x is destroyed. Probably uses only one asm instruction
    std::cout << x;
}

Heap example:

int main()
{
    int y = 0;
       
    int* temp; //sets aside 8 bytes (on my machine)
    temp = new int; //function call, costly, might call system function to allocate more memory
                    //sets aside another 4-8 bytes (might be aligned)
    while(std::cin >> *temp) //I hope compiler will optimize dereferencing here.
        y += *temp;          //In other case it is one instruction more per dereference.
    delete temp; //Another function call and allocator manipulation.
    //note that 8 bytes taken by pointer itself are not freed
    std::cout << x;
}

[IceThatJaw]

Pointers make programs smaller and if used correctly, more memory efficient. Like the poster above said, dynamic heap variables are more expensive than compiled variables.

And if you dive into OOP you might want to know that Polymorphism is very expensive as well. It's not so expensive that it cancels out it's worth for the programmer though.

[jasonrobertz357]

False. Heap memory are usually allocated and freed slower than stack.

As I know, memory on the stack can only be freed by waiting the block where it was created was done but with pointers, you can free the memory manualy.

As you said, memory in heap is slower to free than the stack But what should I do with a situation like this?

void blabla() {
    unsigned short int asd = 123; //Let's say I'm done with it after initialization
    //the rest is 500 lines of code
}

Is the speed of freeing the memory still matters for the following code above?

If

the less memory you use, the faster the program is

is true? I think using pointer is better? I'm not sure.

[jasonrobertz357]

Pointers make programs smaller and if used correctly, more memory efficient

Does this means the pointers make the program faster if used correctly?

And what do you mean by expensive?

Sorry, I'm just new in programming (I'm not even done yet with the book I'm using to study).

[IceThatJaw]

With pointers you can declare memory for variables only when you need to use them and the second you are finished you can free that memory.

As you'd imagine, this will make you program very memory efficient. Ignore the comment I made about making it smaller. I meant memory wise but worded it incorrectly.

As far as speed goes, that has more to do with the your logic and how much function/method/polymorphism/Database overhead you have.

[cire]

As you said, memory in heap is slower to free than the stack But what should I do with a situation like this?

void blabla() {
    unsigned short int asd = 123; //Let's say I'm done with it after initialization
    //the rest is 500 lines of code
}

Refactor your poorly designed, bloated function. If you're done with a variable immediately after initialization then:

    {
        unsigned short int asd = 124 ;
    }

limit it's scope.

IceThatJaw wrote:

Pointers make programs smaller and if used correctly, more memory efficient

jasonrobertz357 wrote:

Does this means the pointers make the program faster if used correctly?

The statement you're responding to is not true in any general sense. So, no, it doesn't mean pointers make the program faster.

The thing you should be concerned about right now is making your programs work correctly. Worry about fast when fast becomes an issue.