Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


#ActualHodgman

Posted 15 February 2013 - 07:54 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.
}

#3Hodgman

Posted 15 February 2013 - 07:51 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();
  Object& obj2 = *(new Object());
  Object obj3();
  delete obj1;
  delete &obj2;
}//obj3 deleted here 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.
}

#2Hodgman

Posted 15 February 2013 - 07:50 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();

  Object& obj2 = *(new Object());

  Object obj3();

  delete obj1;

  delete obj2;

}//obj3 deleted here due to the stack unwinding

 

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 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.


#1Hodgman

Posted 15 February 2013 - 07: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* obj = new Object();

Object& obj = *(new Object());

 

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 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.

PARTNERS