• Advertisement
Sign in to follow this  

Model Design Pattern

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

First let me say hello, as this is my first post on gamedev.net -- now to jump straight to the good stuff (aka code): I'm writing a simple little program to try out some new design patterns and have run into a conundrum on how to go about some details. The language is C++, and the compiler is MS Visual 2003. I realize that I'm not using some of these in the classic way (The factory doesn't so much construct as provide a consistent reference point for a mesh and creating new reference points for example) so bear with me as I haven't come up with a better name for some of these yet. I'll try and be as concise as possible in describing this. class Game { vector<ModelFactory*> Factories; // holds list of all the model factories. } class ModelFactory { public: Model& create(location, orientation, etc.); private: int modelcount; } class Model { private: ModelFactory* origin; // the factory that made it } The long of the short is that I want the ModelFactory to unload itself if no models are using it -- I've considered 2 ways to do this thus far: ~Model { if(0== --(origin->modelcount) { delete origin; } } and a similar method where the factory has a 'remove' method (probably needing to be passed a model pointer and checking if its origin == itself) Unfortunately both of these involve either friending or making a get method on something I don't want directly exposed. There is also the problem of the vector above needing to be informed when a modelfactory is deleted. But since I don't want to tie modelfactory to the game class I don't see a way to go about this with any elegence whatsoever. Any suggestions or thoughts?

Share this post


Link to post
Share on other sites
Advertisement
Take a look at boost::shared_ptr<>.

It's a smart pointer which does external reference counting, so the object it's pointing at will not be deleted until the last pointer to is gets deleted. The good thing is, that the class does not have to be modified in any way because the reference counter for it is allocated on behalf of the shared_ptr<> from the heap and deleted again when it reaches 0.

-Markus-

Share this post


Link to post
Share on other sites
Futhermore, check out the Loki Library by Andrei Alexandrescu.

http://sourceforge.net/projects/loki-lib/

Kuphryn

Share this post


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

  • Advertisement