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),...

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.

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...

<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...

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...