4 ms·
Let's say you have a Lock object that wraps a pthread_mutex_t. How do you expect clients to determine when they should Dispose it? The problem with Dispose is
by millstone 11y ago
Let's say you have a Lock object that wraps a pthread_mutex_t. How do you expect clients to determine when they should Dispose it?
The problem with Dispose is that it's infectious. If one of your instance variables needs to be Dispose'd, then you do too. This is all sorts of bad: it violates LSP, leaks implementation details, adds compatibility constraints, etc.
- fleitz 11y agoReference counting? The second line is why GC is a lot of hype... eventually you need a pthread_mutex_t and GC programming becomes just as onerous as reference counting.
- StillBored 11y agoI totally agree. This is one of a number of concepts that keep me away from most GC'ed languages. BTW: Even in C++ though, I wouldn't use a pthread mutex directly, or in a wrapper class if I haven't banned exceptions. The "correct" way is to create a resource wrapper class without public lock/unlock calls and then a second RAII lock class that can lock/unlock the wrapper. Then if an exception happens while holding a lock you at least have a chance of properly unlocking it, or noticing that it wasn't unlocked.