3 ms·
Well, Yah if you didn't use it.. But AFAIU the point is that it won't happen if you have to call a dispose method (the dispose operations would block the finali
by StillBored 11y ago
Well, Yah if you didn't use it.. But AFAIU the point is that it won't happen if you have to call a dispose method (the dispose operations would block the finalizer)...
AKA, if you have an object that needs to be disposed, and the finalizer is running concurrently with the constructor then that is because you forgot to call the Dispose() method and any complaining it does is valid.
EDIT: Although, thinking about it more, the bigger problem is the partial construction case, where you need to be really careful how you set/unset the flag used to determine if the dispose method is called. But if something is bad enough to result in the construction phase failing in some really bad way, then there should be noise about that too. I would hope!
- millstone 11y agoLet'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.