Jump to content
  • Advertisement
Sign in to follow this  
AmigaUser

Keeping object instances alive?

This topic is 2950 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

I'm new to this so please excuse my ignorance, I have function in a header file that creates numerous object instances.

This header file is included in the main source file and when the aforementioned function is called it produces the objects as required, however upon completion and the focus is returned to the main source file the instance variables are no longer accessible to me.

The CPP file has this:

GenerateNPCs(2);

And the included header file has:

class NPC
{
public:
int vision;
}

and (in brief)

int GenerateNPCs(int number_of_NPCs_to_create)
{
NPC Plyr[100];
...
Plyr[x].vision = iRnd(60);
...
Return 0;
}

When doing a step by step run-through GenerateNPCs(2); amongst other things gives Plyr[x].vision a random value, however when after we hit the Return 0; the debugger gives me the following error;

Plyr[0].vision CXX0017: Error: symbol "Plyr" not found

By inaccessible I mean that once the function is completed and returns to the next step I can no longer access the Instance variables created.

I'm not sure if what I want is possible but after calling GenerateNPCs (and its completion) I would like all object instances and associated variables to remain accessible for manipulation.

I've been told that my object instances are being destroyed by the ending of the GenerateNPCs function above, how do I stop this and make them available to all my functions?

Share this post


Link to post
Share on other sites
Advertisement
Plyr is a local variable not an instance variable. So it's gone after the function finishes. Why not have the GenerateNPCs function return the array? You might also reconsider putting function definitions in your header files.

Share this post


Link to post
Share on other sites
If that array (Plyr) is being declared inside of the GenerateNPCs method then it's going out of scope by the time it exits the method. Basically, Plyr only exists while you're in GenerateNPCs.

If you're wanting to extend the life of that array outside of the method then you need to look into either declare it in another scope rather than a methods scope. Try to find some information about scopes.

If you're just wanting to learn how to keep an object declared in a method from going out of scope, you're going to want to look at pointers.

Share this post


Link to post
Share on other sites
When your function goes out of scope, anything declared in the scope of your function will be destroyed. The only ways to avoid this are to somehow pass back the data, or allocate the data on the heap and pass a pointer.



int GenerateNPCs(int number_of_NPCs_to_create, std::vector<NPC> & Plyr)
{
NPC curr;

...
curr.vision = iRnd(60);
Plyr.push_back(curr);
...
return 0;
}

std::vector<NPC> Plyr;
Plyr.reserve(100);
int result = GenerateNPCs(100, Plyr);







This code allows you to pass in a vector by reference that you wish to add the NPC objects to.



std::vector<NPC> GenerateNPCs(int number_of_NPCs_to_create)
{
std::vector<NPC> Plyr;
Plyr.reserve(number_of_NPCs_to_create);
NPC curr;

...
curr.vision = iRnd(60);
Plyr.push_back(curr);
...
return Plyr;
}







This substitutes the return value with the NPC vector, which allows you to return it from your function. The downside is that the Plyr object will be copied when you return it, which can be costly if Plyr and/or NPC objects are large.



boost::shared_ptr<std::vector<NPC> > GenerateNPCs(int number_of_NPCs_to_create)
{
boost::shared_ptr<std::vector<NPC> > Plyr(new std::vector<NPC>());

Plyr->reserve(number_of_NPCs_to_create);
NPC curr;

...
curr.vision = iRnd(60);
Plyr->push_back(curr);
...
return Plyr;
}







Basically, whats happening here is that I'm doing the same thing as before, except I'm allocating the std::vector on the heap and passing back a pointer to it. This method doesn't incur the copy penalty. The downside is that dynamic allocations have to be freed later. So what I do to mitigate that is use a boost::shared_ptr, which retains a reference count and will auto-magically delete the vector when nothing else references it.

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!