Object counter for classes

[ricfow]

Suppose I have the following hierarchy of classes:

class Entity{
public:
Entity(int idValue){id=idV alue};
private:
int id;
}

class Vertex: public Entity
{
public:
Vertex(): Entity(0){};
// More stuffs
}

class Edge: public Entity
{
public:
Edge(): Entity(1){};
// More stuffs
}

class Face: public Entity
{
public:
Face(): Entity(2){};
// More stuffs
}

The aim is to implement an object counter for classes Vertex, Edge and Face. This is very import in the context of my project. I figured out the following redesign:

class Entity{
public:
Entity(int idValue){id=idV alue; objectCounter[id]++};
~Entity(){objec tCounter[id]--};

int howManyObjects( ){
return objectCounter[id];
}
private:
int id;
static int objectCounter[3];
}

int Entity::objectC ounter[3] = {0,0,0};

Before my questions, a certain improvement in the code style would be to create enum {VERTEX,EDGE,FA CE} and substitute the magic numbers 0, 1 and 2.

In the article I considered the proposed approach too much complicated by using templates. Supposing that the counters are only for objects of these classes (or a fixed number of classes that I known a priori), do you have any criticism about my approach, possible improvements and mostly important, potential pitfalls?
Your help will be much appreciated.

[jkmyoung]

What would be the point of the enumeration, if you are still going to access the counter with an array?

Is space an issue?
Your declaration does leave Entity as a public class; other people will be able to call Entity(1), Entity(2), without being of the specified type.

[ricfow]

<What would be the point of the enumeration, if you are still going to access <counter with an array?
The enumeration is to avoid using the numbers 0,1 and 2. The constructor of Vertex would be, for instance,
Vertex::Vertex( ) : Entity(VERTEX){ }
instead of
Vertex::Vertex( ) : Entity(0){}

----

<Is space an issue?
<Your declaration does leave Entity as a public class; other people will be able to <call Entity(1), Entity(2), without being of the specified type.

Size is no an issue, but I would not like to spend unnecessary bytes. You are right, objects of class Entity cannot be instanciated. What do you suggest?

Thanks in advance,

[weaknessforcats]

Tell me again what this object count if for? With that static variable, your design is single-threaded. Single-threading does not work with modern multi-threaded software.


However, assuming you need it, I suggest you remove the object count from the Entity class. Instead, write a Factory class that has methods for
CreateVertex(), CreateEdge(), etc. and keep the counts as data members of the Factory class. That way you know how many objects of each type the Factory has created. Check out the Parameterized Factory aspect of the Factory design pattern.

Ideally, CreateVertex() would return a Handle to a Vertex (Handle<Vertex> ) and for beginners it would return a Vertex*. There is an article on Handle classes in the C/C++ Insights.

[ricfow]

First of all, thank you for the interest and suggestions.

The reason I tryied to introduce the objects counter is the following:
Each instanciated object must have a unique ID among all objects
of a certain class. The IDs must belong to the range [1,totalNumberOf Objets].
I figured out this strategy because it will be very easy to read/write the
objects data to the disc. Vertex, Edge and Face are not the only entities,
there are many others composing a geometric/topologic data structure.
The main feature of the data structure is that the objects have a lot
of pointers. For instance, a edge have pointers to two vertices, a face
have pointers to edges, etc. When the objects are being saved to the disc,
I must substitute the pointers address by numbers and that's when the ID
of the entities come in handy.

The problem with the counters is that when an object is deleted, I would
like to use its ID again. Of course, I could always generate new IDs (bigger)
but I would not like to follow this way. Instead, I'm thinking to use a stack
to keep track of the IDs associated to the deletes objetcs, and reusing them again
when new objetcs are created. Maybe there is a simpler solution...

If you agree with my solution, I could
move the role machinery for the counters and IDs generation
to the Factory you have suggested.

I hope I've made myself clear. Thanks again.

[weaknessforcats]

So, I suggest you write a singleton class that is responsible for supplying those unique IDs. This class can implement a data base of previously supplied IDs or it could implement an algorithm much like Microsoft's Guidgen.exe.

Read the C/C++ Insight article on the Singleton Design Pattern for tips on how to implement this.

Then, have your constructor in your class access the singleton to get the ID for the object being constructed.

At this point a Factory does not appear to be required.

[ricfow]

Wouldn't be interesting to create this singleton class and assign it
the following responsabilitie s:
1)- Create the entities (createVertex() , createEdge(),.. .)
2)- Delete the entities
3) Manage the IDs
?
The reason to include the deletion of the entities is to help to manage
the IDs, because it is necessary to keep track of the deleted ones.

thanks again.

[weaknessforcats]

What you are talkin about is using a parameterized factory. You don't need a singleton for that. Which, incidentally, I think is a very good idea. The reason is the factory can be created on the heap, the objects created, and then the factory can be deleted thereby keeping your runtime footprint small.

Factory* f = new Factory;
Vertex* v = f->CreateVertex();
//etc...
delete f;

I suggested the singleton as a source of IDs so that the entire program could be assured that each ID was unique. Here the Factory is the one accessing the singleton.

You don't want the factory to be a singleton since you don't want to have it in existence for the entire program.

[ricfow]

In fact the factory must exist for the entire execution, because my program is a geometric editor. So, creating and deleting vertices, edges, etc happen all the times. So I believe that keeps the factory as a singleton is worthwhile.

I also believe that delegating the responsability of managing the IDs to the factory is also interesting. The additional cost would be that all objects must deleted using deleteVertex(my vertex), deleteEdge(myed ge), etc.. also implemented in the factory.
In this case, it would be more than a 'factory', but something like a
geometricEntiti esManager or simply EntitiesManager ...

[weaknessforcats]

Well, there you go. Once again in the OO world there are multiple solutions. Just pick one and run with it.