Lübbe Onken wrote:
>
> This can happen if cachedDir points to an object, that has been destroyed
> somewhere else. It can become a real bitch to track down, because depending
> on your 'luck' the place that cachedDir points to can still be a valid
> object of the proper type for some time until the memory really gets
> overwritten.
>
But Stefan has said cacheDir is NULL after the if statement. Even if
the object is deleted elsewhere, his pointer still won't be NULL unless
something explicitly sets it to NULL. He'd still see the AV, but the
pointer would look valid but in this case, the pointer is being set to NULL.
Of course, using something like a smart pointer could have this effect
you describe.
Unless cacheDir is definitely only accessed in 1 thread, then it does
sound like a race condition of some sort.
>
> A good way to get around this is to implement the observer pattern. Short
> version: Each object being watched has a list of its observers. In its
> destructor it notifies the observers of its destruction. It can also notify
> the observers of other changes if need be. Each observer adds/removes itself
> to/from the objects list of observers when he starts/stops watching an
> object.
>
Or a smart pointer class for reference counting the objects.
Cheers
Russell
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Apr 10 10:24:13 2006