16 replies to this topic

[handoman]

Lets say that I want all of my classes to have their own private static int called "numberOf" that is basically has the total number of instances of that class. Right now I have a way that works simple enough: typing the declaration/definition of the variable for every class and new class I create and their constructors/destructors. it works but I was wondering if there is an easier way to do this, to have all of the classes have a their own (private/non-inherited) static variable of the same name, or is my way just basically it? 

[L. Spiro]

You basically just said the solution so I am not sure what you want.
Are static members not the solution?
 
 

class A {
private :
    static int    m_iCount;
};
 
A::A() {
    ++m_iCount;
}
A::~A() {
    --m_iCount;
}

Is this not what you wanted?


L. Spiro

[Servant of the Lord]

If there is some consistent reason that all those classes should have that type of variable, then maybe inheritance is what you want.

 

If the classes are different classes with similar interfaces, and inheritance doesn't make sense, then create a template* .h and .cpp, and either copy + paste it when you need it (Doing a 'Replace All' on the classname to the new class' name), or see if your IDE of choice has build-in support for template files - many do.

 

*I'm not talking about C++ templates, I mean just create a file and use it as a template

 

But if you are able to post some real examples of actual classes you are creating, we could offer better suggestions.

[EWClay]

You could make a templated counter class that has its own constructor and destructor. Add the corresponding counter object as a member of each class you want to count. You can get around having to define the static variable by putting it inside a function.

Sorry I'm on my phone so I can't write out the code.

[handoman]

haha yea @Spiro, Thats what I have already. But if I want to do that for every class, I would have to write that over and over. for example

class visible //can see it, but can't touch it
{
    static int numberOf = 0;
public:
    visible(){numberOf++;}
    ~visible(){numberOf--;}
};

class physical // can feel it but can't see it
{
    static int numberOf = 0;
public:
    physical(){numberOf++;}
    ~physical(){numberOf--;}
};

class human: public physical, public visible // can see it and touch it
{
    static int numberOf = 0;
public:
    human(){numberOf++;}
    ~human(){numberOf--;}
};

class girl: public human // a human girl
{
    static int numberOf = 0;
public:
    girl(){numberOf++;}
    ~girl(){numberOf--;}
};

visible sky;
physical boundary;
human being;
girl princess;

 

at the end of this I would have: visible::numberOf = 4, physical::numberOf = 4, human::numberOf = 2, girl::numberOf = 1. 

[SiCrane]

There's the CRTP:

template <typename T>
class Counted {
  protected:
    Counted() {
      ++number_of;
    }
    Counted(const Counted &) {
      ++number_of;
    }
    ~Counted() {
      --number_of;
    }

    static int number_of;
};
template <typename T>
int Counted<T>::number_of = 0;

class Human : private Counted<Human> {
  // whatever
};

class Girl : public Human, private Counted<Girl> {
  // whatever
};

[L. Spiro]

Curiously recurring template pattern is likely your best bet.

 

 

L. Spiro

[Alpha_ProgDes]

There's the CRTP:

Spoiler

template <typename T>
class Counted {
  protected:
    Counted() {
      ++number_of;
    }
    Counted(const Counted &) {
      ++number_of;
    }
    ~Counted() {
      --number_of;
    }

    static int number_of;
};
template <typename T>
int Counted<T>::number_of = 0;

class Human : private Counted<Human> {
  // whatever
};

class Girl : public Human, private Counted<Girl> {
  // whatever
};

 
 

Curiously recurring template pattern is likely your best bet.
 
 
L. Spiro

 

Is that really the name?

[L. Spiro]

Yes: http://en.wikipedia.org/wiki/Curiously_recurring_template_pattern

 

 

L. Spiro

[handoman]

oh cool, I was wondering how I would do it with a template. So any class that I want to have an instance counter can inherit that template

Edited by handoman, 28 February 2013 - 06:37 PM.

[Servant of the Lord]

Yep. I've only used it twice before, and both times I felt slightly proud and slightly disgusted at the same time. 

[handoman]

one question: what is the difference, or the point of having two constructors:

Counted() {
      ++number_of;
    }
Counted(const Counted &) {
      ++number_of;
    }

Edited by handoman, 28 February 2013 - 06:44 PM.

[L. Spiro]

One is a copy constructor which can be invoked in several circumstances.

 

 

 

A a;  // Normal constructor.
A b( a ); // Copy constructor.
A c = a; // Copy constructor.
 

 

 

L. Spiro

[Khatharr]

Curiouser and curiouser...

[larspensjo]

There may be a more general solution to your problem, and that is to use Entity Component System design pattern. In principle:

1. The Entity is a general purpose object. Usually, it only consists of a unique id and a container.
2. The Component consists of a minimal set of data needed for a specific purpose. In your example, you would have a "Visible" component and a "Physical component".
3. The System manages the behavior of the components.

In your example, a human would be an Entity with a "Visible" and a "Physical" component attached to the container. A Component can have a state, but it doesn't have to.

 

And then you would have one system that manages all Entities that use the "Physical" components, and another system that manages all entities with "Visible" components. These systems would be independent of each other. There may be variations, where a System need to access entities that consists of a combined list of components.

 

See Anatomy of a knockout and Refactoring Game Entities with Components for more information. I think the https://github.com/alecthomas/entityx source code looks promising. It also has a good support for using events to communicate information between systems (and other modules), instead of having components know about other components.

 

 

The disadvantage of the ECS may be that it adds some code initially, and it also adds some communication overhead. If you have a small system with not much more than stated above, then ECS will probably be an overkill. The advantage is that it has a very high degree of flexibility. It is much easier to add functionality, and provide alternative functionality.

[handoman]

Hmm, ECS seems interesting, so according to my research, I would have Human( an entity) and instead of inheriting visible and physical, it has instances of visible and physical?

[larspensjo]

Hmm, ECS seems interesting, so according to my research, I would have Human( an entity) and instead of inheriting visible and physical, it has instances of visible and physical?

Right. Now suppose you have a drawing function. This would be a "System" that iterates through all entities that have both a physical and a visible component, and draw them. The visible component could typically have some information about how a thing should look like (e.g. human, monster, sparks flying around, flying arrow), and use the physical component to know where to draw it.

 

Another system could be a collision detection. It would iterate through all entities that have a physical component, as it wouldn't care how the entity is drawn. This system would then detect "arrows" that collide with "monsters", and generate an event when that happens. It shouldn't need to understand what an arrow is, and what it means when another object is hit by an arrow.

 

Yet another component could be health data, and a system that manages health. Health components would be attached to the human and monster entities, but not to arrow entities. The health management system would subscribe to the event generated from collisions and update health accordingly. This system could also now and then iterate through all entities with the health component, and regenerate health.

 

Of course a real game is much more complicated than this, and there are new design problems to solve. But I think the ECS way is interesting. Using events isn't part of the original ECS pattern, but I think it is convenient and will decouple dependencies.