steven_shaw at iprimus.com.au
Thu Jul 1 11:42:32 UTC 2004
On Wednesday 30 June 2004 14:25, Toby Ovod-Everett wrote:
> For instance, say I have a class that interacts with the Windows registry.
> In one block, I access a key and read through its values. The block closes
> and then I go to delete the key. If the finalizer for the object that
> interacts with the key doesn't run before I attempt to delete the key, I
> will have problems because the Windows registry system won't allow deletion
> of a key for which there are open handles.
I agree with the other respondant - I don't think you need to design it this
way. In this case (i.e your windows registry example), I'm sure you could use
explicit resource management (hidden away appropriately) and have easy to
understand, maintainable code. If it gets a little more complicated, it best
interface may be "transactional".
> The requirement that I always
> explicitly close objects to ensure that finalizers run immediately begins
> to look an awful lot like the requirement that I hand back malloc'ed memory
> . . . :)
This approaches a good argument against explicit resource management. We know
that memory management works better when you don't have to manage it
explicitly. However, in this case you generally have to be happy to have
finalisation happen "sometime soon". Even with reference counting, you have
cycles which are collected every now and then by a mark-sweep or something.
I wonder what makes most resources unlike memory? Maybe it's that most
resources are held for short periods of time (although they say the same
about memory...). Probably it's more something to do with the number of
references to a resource. If anyone knows the answer please chime in.
More information about the Self-interest