int is 4 bytes in 32-bit environment -> Person is 18 bytes
If you want a 1-dimensional array of 20 entries:
a)
Person arP[100];
100*18 bytes = 1800 bytes. That's not terrible, but also not good, especially when you don't always need 100 persons.

b)
Person *arP;
// allocate
arP = new Person[Size];
Good. This takes up 4 bytes on the stack. When allocating, you need Size*18 bytes + allocation information on the heap. That's the best solution. It's easy to resize and doesn't take up too much memory.

c)
Person **arP;
// allocate the first part
arP = new Person*[Size];
// allocate the second part
arP[index] = new Person;
Unnecessary. This takes up 4 bytes on the stack. The first part is when you know you many persons you'll need at max. It takes up Size*4 bytes + alloc info on the heap. When you really need a place, you allocate again: 18 bytes + alloc info. Unless Person needs more than 100 bytes of memory this doesn't make sense. It's hard to keep track of all the pointers and very probable that you get memory leaks or access violations. The good part is that you have the most control of how much memory is used, but you waste memory for the additional poiners. I wouldn't do such a thing. It's easier to resize a normal dynamic array.
Person *arP[100];
// allocate
arP[index] = new Person;
This is not much better. You have only one layer of pointers (only 100 ), but it doesn't save much. This takes up 400 bytes on the stack.



To accomplish what this does, I would use a single/double linked list (STL container "list" or "slist"). It's absolutely perfect: The animals are added only at one end, are only searched sequentially and removed anywhere. It would free you from all the hard pointer work.