mud++0.35/etc/
mud++0.35/etc/guilds/
mud++0.35/help/propert/
mud++0.35/mudC/
mud++0.35/player/
mud++0.35/src/interface/
mud++0.35/src/os/cygwin32/
mud++0.35/src/os/win32/
mud++0.35/src/os/win32/bcppbuilder/
mud++0.35/src/osaddon/
mud++0.35/src/util/
Automatic Garbage Collector (GC)
I have added it to mud++ to assure that objects which have references on
VM stack do not get deleted as long as there is even one pointer to them.
This allows implementation of VM sleep() and VM static/object memory.

Main code of mud++ is in control of creating and destructing objects.
Only thing you have to keep in mind when coding c++ part is to use
obj->fordelete() instead of delete obj for all objects inheriting from
VMObject. Once object is marked by fordelete() call it is illegal to
reference it from main c++ part (just as it would be deleted).
From this moment on, only GC and some VM handling routines are allowed to
manipulate them.
It is wise to check if obj->extract() is available and should be applied.
This is true for some objects like Action or Affect.
Maybe in future will will move to virtual fordelete(). Then fordelete() would
take care of all needed dereferencing/unregistering in mud++, and ~ destructor
would only care about freeing memory. For now extract() plays the role of
virtual dereferencer.


What happens to obj when fordelete() is called ?
Normally, just don't care about that , but if you want to know, here it is.
Pointer to object is put onto GC stack at the time object is created.
Object is also marked with bit indicating that it exists in C++ world, so
it would not be collected, even if no VM keeps reference to it. When
fordelete() is called this bit is cleared and object can be reclaimed
during next gc run.

When GC start to work it cleans marks on all objects on its stack.
Then it goes trough all VMs stacks and static VM variables, and marks
objects which are referenced there. If these objects have local VM memory
they mark VM objects referenced in it and so long.
After that all objects on GC stack which do not have IN_C_WORLD bit, and are
not GC_MARKED can be safely collected.
There is no risk of loop, because object will try to mark its local memory
only first time it gets marked.
It is possible that GC run will not collect all possible objects - if 
destructor of object call fordelete() for it members, thay may, but do 
not have to be deleted. They will be collected next time.

Mud++ GC is kind of mark&sweep collector. Unfortunately there is a need
for checking most pointer writes in VM, because Strings are reference
counting based.