diff --git a/doc/refcounting.txt b/doc/refcounting.txt
index a3cd020583d4c850005ce78b2fd080961a4708b0..e409262db7ca0f8d10d7242f2d4b924c28034cbd 100644 (file)
--- a/doc/refcounting.txt
+++ b/doc/refcounting.txt
examples are elements in a doubly-linked list with "prev" and "next"
pointers, and nodes in a tree, where a parent keeps a list of children, and
children keep a pointer to their parent. If both cases, if there is a "ref"
-in both directions, neither parent nor children can ever get freed.
+in both directions, neither object can ever get freed.
Because of this, circular data structures should be avoided when possible.
When they are necessary, try only "reffing" in one direction
ANCHORED OBJECTS
-The garbage collector can see pointers in:
+As a rule of thumb, the garbage collector can see pointers in:
* global/static variables in the program
Since a lot of important objects (e.g. gtkmm widgets or Glib collections)
fall into the latter category, I've provided the GC::Anchored class from
which garbage-collector managed classes can be derived if they may be
-remembered exclusively by such places. As noted earlier, the associated
-ref and unref functions are GC::anchor() and GC::release(), respectively.
+remembered in such places. As noted earlier, the associated ref and unref
+functions are GC::anchor() and GC::release(), respectively.
For most refcounted objects, a nonzero refcount means "this object is in
use", and a zero refcount means "this object is no longer in use, you can