CoCoA » CoCoALib

[during meeting in Aarhus with Anders, Anna and Christof]
It was pointed out that external libs may want to store CoCoALib values in global variables; this proposal would allow such values to be properly cleaned up at the end of program execution.

Here is a "trick" which could work:
define a function void CallDtor(void* dtor) { dtor(); } and then
to register an argumentless pseudo-dtor dtor0 we could register the pointer
&dtor0 and the function CallDtor (which has the correct signature).

This would allow all entries in the pseudo-dtor stack to be pairs of void* and void (*fn)(void* ptr) where the fn is either CallDtor which expects its arg to be a pointer to an argumentless pseudo-dtor, or fn is a 1-arg pseudo-dtor whose arg is a pointer to the object to be destroyed.

Is this a "neat trick" or an "evil hack"? I'm unsure. It uses void* to hide a type ambiguity...

• void* a point to some object to be destroyed
• void (*dtor1)(void *ptr) pseudo-dtor for passed in object
• void (*dtor0)() argumentless pseudo-dtor

Only one of dtor1 and dtor0 would be non-NULL.
The disadvantage of the clean impl is that it wastes some space: 1 or 2 pointers in each entry would be unused.

It seems that C++ STL provides no guarantees about the order of destruction of elements in a container: see http://stackoverflow.com/questions/6169125/order-of-destruction-of-elements-of-an-stdvector

Thus, for instance, a pseudo-dtor for a vector<ring> must go through the rings explicitly one at a time: the following code might work

  const long n = len(v);
  for (long k=n-1; k >= 0; --k)
  {
    v.back().RunDtor();
    v.resize(k);
  }

or maybe the even simpler

  while (!v.empty())
  {
    v.top().RunDtor();
    v.pop();
  }

NOTE (2015-10-19) my earlier suggestion to make the dtor for the entries in the stack actually run the registered dtors was A BAD IDEA because internally the stack operations copy and delete the stack entries, so rings were destroyed too early! Ouch!

I wonder whether the possibility to register the pair ptr+dtor should be removed later on. At the moment it is used only in RingQQt (in file PolyRing.C:125), and that use will probably disappear if/when we implement a global register for rings (assuming that any rings left in the register at the end will be automatically destroyed by GlobalManager).

Perhaps I'll word the documentation to discourage using it...