Itt leírtam, mi előny származhat abból, ha a GC a nyelv megkerülhetetlen része. További előnyök, amelyek akkor is érvényesek, ha csak a kód egy része használ GC-t:
- egyszerűbb contract: Egy C vagy C++ API tervezésekor mindenhol megfelelően specifikálni kell, hogy mikor kinek a felelőssége az paraméterként átadott, vagy visszatérési értékként visszaadott objektumok felszabadítása. GC használatakor ez nem kérdés.
- egyszerűbb memóriakezelési minták: a) mehet stackre, vagy túl kell élni-e ezt a függvény? b) lehet-e preallokálni a hívónál és oda beírni az eredményt, vagy mondjuk polimorf a visszatérési érték? c) elég egyszerre egy referencia az objektumra? => auto_ptr / unique_ptr d) ha osztott a birtoklás, akkor vajon aciklikus-e a hivatkozási lánc? e) ha kialakulhat körkörös hivatkozás, meg lehet-e törni a láncot alkalmasan választott a weak pointer elhelyezésével? -- ezeket a kérdéseket mind végig kell gondolni kézi memóriakezelésnél, GC-snél pedig nem.
- ha az előbbi kérdések mindegyikére 'nem' a válasz: akkor már csak egy tracing GC segíthet.
- adott memóriakezelési patternre lehet, hogy éppen egy adott GC fajta a leggyorsabb.
Végülis az 1-2 pontokra rá lehet fogni, hogy az ember lusta átgondolni, hogy mikor kellene a dolognak felszabadulni, és oda tenni a delete-et / free-t. De azért azt vegyük észre, hogy néha nem hátrány, ha az ember bitbaszakodás helyett az eredeti probléma (aminek megoldására a program készül) megoldásával foglalkozik.