i want a manager class, that is basically stl container class. for all my other classes.
so that when i create a class, i can put it into the stl container.
in the main loop i can do some thing like
for (int i = 0 ; i < container.size() ; i ++)
{
conatiner->AI();
conatiner->Move();
conatiner->Fire();
conatiner->Other();
}
but i need to be able to add from any class, cause the class might have to create stuff its self
is there any good articles how to do this please.
i figure it will have to be global and instanced only once
can you point me in the direction of how to impliment a manager class?
Would this not mean you would have to know what class was in what element before you could reference to specific members?
Author
Quote:Original post by KyleM
Would this not mean you would have to know what class was in what element before you could reference to specific members?
no , cause all subsequent classes are inherited and polymophismed , so all classes will have these basic funtions , with these i can just about do everything .
but i need a manager class to do this , other wise it will get messy
If you have a base class, and everything else inherits from it, then you can just put them all in an stl container without needing a manager class.
#include <vector>#include <iostream>class Base{ public: virtual void Update() = 0;};class Derived : public Base{ public: virtual void Update() { std::cout << "d" << std::endl; }};int main(){ std::vector< Base * > manager; manager.push_back( new Derived ); //........... manager[0].Update(); delete manager[0]; manager.pop_back(); return 0;}Quote:Original post by thedodgerukQuote:Original post by KyleM
Would this not mean you would have to know what class was in what element before you could reference to specific members?
no , cause all subsequent classes are inherited and polymophismed , so all classes will have these basic funtions , with these i can just about do everything .
but i need a manager class to do this , other wise it will get messy
Ah, I see. Sorry about that, I am fairly new and was just clearing some stuff up for my own understanding.
im curious, are you looking for a container class for a bunch of extremely similar objects? like an object class where each object is a different kind object in the scene?
if not, i dont see a point to the container. or am i missing something
if not, i dont see a point to the container. or am i missing something
This is actually not a very good idea, for a number of reasons.
First, you shouldn't want to put "any" kind of object in this mythical container -- you should only put objects that conform to a particular interface in a container, and only if those objects truly make sense in such a grouping for processing or organizational purposes. Homogenizing interfaces for the sake of homogenizing interfaces leads to inefficient, messy code.
Second, "managers" are generally unnecessary, and usually exist because a programmer did not apply enough thought to up-front design. From the scenario you've described, you need little more than a common base class or interface that exposes the functionality you expect your grouped objects to have, and a simple SC++L vector to store those instances in. Plus, perhaps, a function to take that vector, iterate it, and invoke the appropriate methods on each object.
The only thing I'm unclear on is the "creating stuff itself" point made here:
because that isn't sufficiently explained.
Basically I think you need to describe your problem better, but there's almost certainly no need for a "manager" here -- or if there is, there is a way to approach the problem so that the new type represents more accurately the behavior it actually exposes.
"Managers" are for sloppy thinkers.
First, you shouldn't want to put "any" kind of object in this mythical container -- you should only put objects that conform to a particular interface in a container, and only if those objects truly make sense in such a grouping for processing or organizational purposes. Homogenizing interfaces for the sake of homogenizing interfaces leads to inefficient, messy code.
Second, "managers" are generally unnecessary, and usually exist because a programmer did not apply enough thought to up-front design. From the scenario you've described, you need little more than a common base class or interface that exposes the functionality you expect your grouped objects to have, and a simple SC++L vector to store those instances in. Plus, perhaps, a function to take that vector, iterate it, and invoke the appropriate methods on each object.
The only thing I'm unclear on is the "creating stuff itself" point made here:
Quote:
but i need to be able to add from any class, cause the class might have to create stuff its self
because that isn't sufficiently explained.
Basically I think you need to describe your problem better, but there's almost certainly no need for a "manager" here -- or if there is, there is a way to approach the problem so that the new type represents more accurately the behavior it actually exposes.
"Managers" are for sloppy thinkers.
@op: sorry to hijack, but...
@JPetrie: If not using a manager, what is a method I might use to ensure that only single instances of resources exist, such as loading a texture the first time it's needed(for one model) but returning a pointer/ref to the already loading object when it's requested by another model instance. In my current code base i have an imanager class that describes the simple interface(create, destroy, get) that my managers use, and overload as needed. I'm currently using one of these managers each for sounds/materials/skins/meshes/textures/shaders,
@JPetrie: If not using a manager, what is a method I might use to ensure that only single instances of resources exist, such as loading a texture the first time it's needed(for one model) but returning a pointer/ref to the already loading object when it's requested by another model instance. In my current code base i have an imanager class that describes the simple interface(create, destroy, get) that my managers use, and overload as needed. I'm currently using one of these managers each for sounds/materials/skins/meshes/textures/shaders,
Author
i have a system working but a little messy
i have a global vector <CBase*> container;
CBase has
int mMeshNum; // referance to a mesh containe class
IModel* mModel; // instancve of the model
bool mIsAlive; // set to alive when created
virtual void AI();
virtual void Move();
virtual void Animation();
virtual void Other();
void RemoveIfDead(int num);
every time i do create an object CBase bullet = new CBullet(1);
// the 1 goes to mMeshNum
it creates the object and automatically adds it to the vector
but the vector is just there bare, would rather put it into a class, to make it neeter
IT works the way i have done it , very well , but a little messy ,if the vector was in a class , would tidy it up a bit
i have a global vector <CBase*> container;
CBase has
int mMeshNum; // referance to a mesh containe class
IModel* mModel; // instancve of the model
bool mIsAlive; // set to alive when created
virtual void AI();
virtual void Move();
virtual void Animation();
virtual void Other();
void RemoveIfDead(int num);
every time i do create an object CBase bullet = new CBullet(1);
// the 1 goes to mMeshNum
it creates the object and automatically adds it to the vector
but the vector is just there bare, would rather put it into a class, to make it neeter
IT works the way i have done it , very well , but a little messy ,if the vector was in a class , would tidy it up a bit
Quote:
@JPetrie: If not using a manager, what is a method I might use to ensure that only single instances of resources exist, such as loading a texture the first time it's needed(for one model) but returning a pointer/ref to the already loading object when it's requested by another model instance. In my current code base i have an imanager class that describes the simple interface(create, destroy, get) that my managers use, and overload as needed. I'm currently using one of these managers each for sounds/materials/skins/meshes/textures/shaders,
This is more properly described as a cache.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
