First, I probably haven't been as active in C++ programming as I could have been. It's basically been either look for a job that doesn't require 5+ years industry experience, look for (unpaid) open-source projects that doesn't demand 5+ years experience, or write code on my own. I've been delinquent in the latter regard. I'm closing down production on my dungeon-crawl game idea and opted for developing a space fighter sim that (hopefully) won't require me to look for hordes of jobless artists, modellers, etc working on my stuff for free. Right now I'm stumped regarding how to implement a certain feature: player-customized ships and equipment. Basically, I want a player to be able to modify basic characteristics of ship (A), including various equipment hardpoints (ha, hb, hc), adding (dh, hetc) or deleting (hd, hetc). I'm also trying to work in the ability to customize equipment (ea, eb, ec). The result is the player could then customize pretty much everything, and have equipment in the ship something like this (pseudocode warning!): A[ha]->E[ea] A[hb]->E[eb] A[hc]->E[ec] The problem is how to implement this in code and manage changes properly. I'm looking at the view of hardpoints being a part of the ship as a doubly-linked list to control access to the hardpoints and the equipment they point to/hold. It doesn't seem that inheritance will work here because hardpoints shouldn't be a kind of ship. The ship should be able to have an unlimited amount of each type of hardpoint, with a minimum number of certain hardpoints, which is why arrays are out of question. Ideally, the hardpoints are supposed to "hold" a unique instance of an 'equipment' object. So right now, I'm thinking the best way to represent this is to have one storage set aside for the "equipment templates" that the player designs and a different storage set for the actual equipment in use on the ship. Pointers from the hardpoints to this list should then give us what's 'in' that hardpoint. Hopefully I've described my design issue and current approach well enough to understand. Thanks in advance.

I wouldnt use auto_ptr, unless you REALLY want an ownership change and thus have things vanish from other locations (such as if you maintain a master list), a shared_ptr might be a better idea (or object cloning)

Quote:Original post by Basiror
//maybe use auto_ptr here

Sound advice otherwise, but unfortunately you can't use auto_ptrs with standard library containers. Their copy constructor modifies its argument (so as to transfer the ownership), but this does not fill the requirements set for container elements. Instead, one could use a boost::ptr_vector.

These are some pretty good ideas. Looking into things, it does indeed look like container classes are the way to go. Thanks for suggesting the Boost libraries, Sharlin. It looks like those will allow me to do all the things I want to be able to do within that framework. Unfortunately, sourceforge has been very slow for me the past few days and it won't reach the download screen for those libraries, so I'll catch them when I can.

Virtual function interfaces between the ship and equipment should work well in this regard. Having an equipment base class was a possibility, but with this framework (container class) it should work well.

As Phantom and Sharlin advised, auto_ptrs are not the way to go here because I do indeed wish to maintain a master equipment list, which I can clone objects from.

Thanks you, all of you.