[cap-talk] GC versus RAII

[Rob Meijer]

On Sat, April 30, 2011 04:50, Ben Kloosterman wrote:
> . A lot of your arguments smell like C++ vs. Java rather than the broader
> topic-relevant issue of GC's relationship to resource management.
>
>
>
>
>
>
>
> Agree ..In the last thread we also showed that C# has significantly better
> resource management than Java with using and IDispose.  So its not really
> a GC  comparison.
>
>
>
> I would also add it doesn’t really matter if 5 % of your code has
> slightly worse OO “purity”   , the cost of this trivial and would even
> outweigh your time thinking about this .

My point is that the OO inpurity has the real potential to spread your
resource management code requirements all over your code base. So even if
only 0.1% of your low level code held a resource, using composition,
failing to use encapsulation and spilling into polymorphism, depending on
your project size and number of levels of composition, ending up doing
more manual resource management than you would have needed to do if doing
memory management manualy (with RAII classes) could be unavoidable.

This means, for small projects or projects not using deep levels of
composition, GC gives you a producivity boost. For larger projects
however, using many levels deep of composition, and polymorphism at many
layers of abstraction, the end result will inescapably be that GC will end
you up with much more manual resource management (try/catc/finaly +
release()) than you would have needed to do if you had to manage your
memory resources yourself.
Memory is just one of many resources in a program. GC makes managing that
resource less work and less error prone and managing all other resources
more work and more error prone.Seems like a reasonable trade, but when
looking at the scaling properties of managing resources that can't be
encapsulated in composition, GC comes out as being a verry expensive
mistake and productivity killer.