summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: 86d1438)
raw | patch | inline | side by side (parent: 86d1438)
author | mental <mental@users.sourceforge.net> | |
Sat, 29 Apr 2006 18:42:29 +0000 (18:42 +0000) | ||
committer | mental <mental@users.sourceforge.net> | |
Sat, 29 Apr 2006 18:42:29 +0000 (18:42 +0000) |
doc/refcounting.txt | patch | blob | history |
diff --git a/doc/refcounting.txt b/doc/refcounting.txt
index a3cd020583d4c850005ce78b2fd080961a4708b0..a27fb21fb4e4b11c2688552c0a2e185fea1518f1 100644 (file)
--- a/doc/refcounting.txt
+++ b/doc/refcounting.txt
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