Jump to content
  • Advertisement
Sign in to follow this  
Nebu

C++ code question

This topic is 3714 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

assuming i have the following:
class Pipeline
{
  list<Object>* renderlist;
  
  void Update(list<Object>* objList)
  {
     renderlist=objList;
     //do stuff..
  }
  void Print()
  {
  //iterate through list, printing info
  }
};

class Bla
{
    Pipeline* pipeline;
    Bla()
    {
      pipeline=new Pipeline();
    }
    void Render()
    {
       list<Object> myList;
       //fill list by iterating other lists and inserting
       pipeline->Update(&myList);
    }     
}

int main()
{
   Bla* bob = new Bla();
   bob.Render();
   bob.Print();
}

why would renderList not point on &myList, resulting in crash on iteration? Thanks, gn.

Share this post


Link to post
Share on other sites
Advertisement
That piece of code is... all kinds of weird. For starters, bob doesn't even have a Print method, I assume you wanted to write
bob.pipeline->Print()


Your immediate problem is that you are storing the address of a variable that goes out of scope:


void Render()
{
list<Object> myList; // create myList on the stack
//fill list by iterating other lists and inserting
pipeline->Update(&myList); // pass address of myList which gets stored
} // OOPS! myList just went out of scope, there could be anything at its address



That being said, it seems like you're overcomplicating things, maybe you could tell us what you're trying to do (instead of an out of context artificial example) .

Share this post


Link to post
Share on other sites
The problem is you're supplying a pointer to a stack variable.


void Render()
{
list<Object> myList; /* THIS GUY IS ON THE STACK */
//fill list by iterating other lists and inserting
pipeline->Update(&myList); /* HERE YOU SUPPLY A POINTER TO A STACK VARIABLE */
}



When the above function terminates, myList is destroyed. Anything that refers to it after Render() terminates is going to blow up.

Share this post


Link to post
Share on other sites
thanks for the replies, sorry for posting at the wrong place and for code mistakes, I was really tired.
back to the topic, so how do I create a function which would be capable creating a list not on the stack and transfer it?
I'd also appreciate if someone could refer me to an article which covers up things like stack,heap that a programmer should be aware of.

Thanks in advance.

Share this post


Link to post
Share on other sites
Quote:
Original post by Nebu
how do I create a function which would be capable creating a list not on the stack and transfer it?


It might be simpler to provide a list to the function, and have the function populate the list instead.


// Note that the list is passed by non-const reference so that
// the function can change it
void func1(list<Object*> &objectList) {
// Add objects to list
}

void func2() {
list<Object*> objectList;
func1(objectList);
// Do something with objectList
}

Share this post


Link to post
Share on other sites
Quote:
Original post by Nebu
thanks for the replies, sorry for posting at the wrong place and for code mistakes, I was really tired.
back to the topic, so how do I create a function which would be capable creating a list not on the stack and transfer it?
I'd also appreciate if someone could refer me to an article which covers up things like stack,heap that a programmer should be aware of.

Thanks in advance.


There are two types of allocations you can use:

1. Allocate on the stack - this happens automatically when you define a variable in your code. Upside is you don't have to worry about allocating memory manually and freeing it up when you don't need it anymore. The variable ceases to exist as soon as execution leaves the scope it was declared in. Downside is you cannot use the variable you have declared this way in another part of your program. You should always use stack allocation unless you really need this functionality (or if you need to allocate a VERY big chunk of memory, but that rarely happens).

2.Allocate on the heap - also called dynamic memory allocation. In C++ you can allocate objects on the heap using the new keyword. Objects allocated this way will continue to exist until you explicitly delete them, using the delete keyword. However, if you forget to do this, you leak memory. As well as you will run into all kinds of nasty bugs stemming from the (over)usage of pointers. General rule applies: don't use it if you don't have to. If you have to, try to hide as much of the responsibilities as possible via concepts such as RAII and smart pointers .

The reason I wrote that you're probably ovecomplicating things is that for example, you use heap allocation all through your code, except the only place where it would make sense :) Maybe you should tell us about the problem you're trying to solve here (e.g. I'm writing a renderer and trying to pass the list of objects to be rendered to it, I wanted to do it like this and this), instead of asking about the details of the solution you think would work. Then we could give you some insight on how it could be solved in a simple way.

Share this post


Link to post
Share on other sites
Quote:
Original post by Morrandir
2.Allocate on the heap - also called dynamic memory allocation. In C++ you can allocate objects on the heap using the new keyword. Objects allocated this way will continue to exist until you explicitly delete them, using the delete keyword. However, if you forget to do this, you leak memory.

3.Allocate on the heap and use smart pointers.

Share this post


Link to post
Share on other sites
Quote:
Original post by DevFred
Quote:
Original post by Morrandir
2.Allocate on the heap - also called dynamic memory allocation. In C++ you can allocate objects on the heap using the new keyword. Objects allocated this way will continue to exist until you explicitly delete them, using the delete keyword. However, if you forget to do this, you leak memory.

3.Allocate on the heap and use smart pointers.


Quote:
... If you have to, try to hide as much of the responsibilities as possible via concepts such as RAII and smart pointers .


:)

EDIT: But you're right, I should've put more emphasis on that.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!