Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 26 Aug 2005
Offline Last Active Feb 25 2013 03:06 AM

Posts I've Made

In Topic: stack vs heap

18 February 2013 - 06:49 AM

Yes, you should use automatic (stack) lifetimes where possible, and heap lifetimes where you have to.
n.b. with your example of using new, it returns a pointer to an object (in Java, every "object"-type variable is implicitly a pointer, but in C++ you need the "*")
  Object* obj1 = new Object();//obj1 is a local variable, that is a pointer to a heap allocated object
  Object& obj2 = *(new Object()); //a reference is pretty much the same thing as a pointer, but looks like it isn't ;)
  Object obj3;//local variable (stack allocation)
  delete obj1;
  delete &obj2;
  delete &obj3;//this is an error! It wasn't made with 'new' so you can't use 'delete'
}//obj3 deleted here automatically due to the stack unwinding

I am also confused by memory managment in c++. When stack object is freed is there a memory "hall" in stack.

You can't manually "free" an object from the stack. Stack frames are pushed and popped for each "block" of code (basically every set of "{ ... }"). Whenever a "}" is reached, all the stack variables that were created in that block are destroyed. So there are never any holes.
For an example of where stack allocation isn't applicable, imagine a function that makes a new monster appear:
Monster* SpawnMonster()
  Monster m;
  return &m;//error! m is created with the same scope as this function. When the function returns, m is "deleted".
Monster* SpawnMonster()
  Monster* m = new Monster();
  return m;//correct, but someone has to delete this at some point, otherwise you've got a memory leak
shared_ptr<Monster> SpawnMonster()
  return shared_ptr<Monster>(new Monster());//also correct. This acts more like what you're used to in Java. When there are no more shared_ptr's that reference the Monster, it will automatically be deleted.


I'm a little confused ;) 

Can you please tell me, in the next example, mainCanon is in the heap or stack?


class Tank{


          Canon mainCanon;



class Army{


          Tank tanks[20];



void main(){

          Army* army = new Army();



Thank You!

In Topic: stack vs heap

15 February 2013 - 11:17 PM

About shared_ptr. I read now that that Bjarne consider this as bad idea and this is considered as bad c++ design pattern. Anyone can put some light on this.

About unique_ptr. I do NOT want to write managed code. Is unique_ptr managed code ???

In Topic: stack vs heap

15 February 2013 - 11:03 AM

Furthermore, stack memory should be avoided when dealing with large sets of data since most operating systems gives a limit for stack allocation (something in the order of 10mb from my experience), so if you try to declare an data array of size bigger than 10mb for example, your program will most likely crash.


Thought it would be worth mentioning since it's a bug very difficult to catch. I don't know what are the workarounds for that so I only use heap for large data allocation.


0.o are you sure about this one? In java, for example, I do sometimes have objects of this size. When I work with images, pdfs...

So I should create objects on stack only if their size < X ??? 

In Topic: stack vs heap

15 February 2013 - 10:27 AM

OK biggrin.png  Now it's MUCH clearer. 

As I see it now, I should use stack vars if and only if it's life span does NOT need to exceed the scope of it's creation {}. 

Also, a "little" advantage of heap vars is that I can free them in the "middle" of the scope, thus the memory usage is a little smaller.

Ok! I will use stack vars where I can !

Thank you all for the valuable answers :)