X-Git-Url: https://git.tokkee.org/?a=blobdiff_plain;f=doc%2Frefcounting.txt;h=e409262db7ca0f8d10d7242f2d4b924c28034cbd;hb=d9ffa851a6119a7730d683479bb80295fa31b09f;hp=a3cd020583d4c850005ce78b2fd080961a4708b0;hpb=86d1438b2218a762b1c50895fbf91732d31f6452;p=inkscape.git

diff --git a/doc/refcounting.txt b/doc/refcounting.txt
index a3cd02058..e409262db 100644
--- a/doc/refcounting.txt
+++ b/doc/refcounting.txt
@@ -69,7 +69,7 @@ breaks down in the presence of objects that reference each other.  Common
 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
@@ -85,7 +85,7 @@ as it added and removed them.
 
 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
 
@@ -108,8 +108,8 @@ It cannot see pointers in:
 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