Hi,
As Greg says, make your static class an instance class (with instance
methods, properties and resources, and your cleanup code in its finaliser)
and then maintain one (and only one) static reference to an instance of this
class.
One nice way of doing this is the Singleton pattern:
http://www.dofactory.com/Patterns/PatternSingleton.aspx
Guaranteeing the thread-safety of a singleton is trickier than you may
expect though:
http://www.yoda.arachsys.com/csharp/singleton.html
Here's a thread-safe singleton wrapper I've used in the past. You can use
this sort of thing to make any instance class which has a parameterless
constructor into a singleton:
namespace SomeNamespace
{
public class Singleton<T> where T : new ()
{
public static T Instance
{
get
{
return Nested.Instance;
}
}
private class Nested
{
public static readonly T Instance;
static Nested ()
{
Instance = new T ();
return;
}
}
}
}
So if your new instance class is called 'MyUnmanagedHandler', you would just
access it in your code as:
Singleton<MyUnmanagedHandler>.Instance
without any need for initialisation or setup at any specific point in your
code.
And then, when the AppDomain is torn down, the finaliser of your
MyUnmanagedHandler class runs and cleans up the unmanaged resources you're
worried about.
Hope this helps,
Geoff
On Thu, Sep 18, 2008 at 3:33 AM, Greg Young <[EMAIL PROTECTED]> wrote:
> why not keep a static reference to an instance of the class instead of
> using a static class?
>
> Cheers,
>
> Greg
> On 9/17/08, Simon Robinson <[EMAIL PROTECTED]> wrote:
> > I have a static class that holds quite a few unmanaged resources (it
> > basically loads/creates a large number of GDI+ bitmaps, brushes and pens
> > that are likely to be used at regular intervals by the application).
> Being
> > concerned about resource cleanup, I naturally ( :) ) thought about their
> > disposal. However, static classes do not allow finalizers to be defined.
> >
> > In one sense that makes sense - the reason for having a static class that
> > manages these resources is that they are likely to be required repeatedly
> > right up until the app shuts down. However I am a bit nervous - this
> means
> > I'm entirely dependant on Windows to release all these resources when the
> > process ends, and although Windows should do that, to be honest I'm not
> > 100% sure I trust it to do so, I'd feel more comfortable if my managed
> > code contained something to explicitly ensure these resources are
> > released. (I trust .NET rather more than I trust the Windows OS :) )
> >
> > Any thoughts? Am I being too cautious when I should just trust Windows to
> > handle resource release, or is there some other way to deal with this
> > situation?
> >
> > ===================================
> > This list is hosted by DevelopMentor(R) http://www.develop.com
> >
> > View archives and manage your subscription(s) at
> http://discuss.develop.com
> >
>
>
> --
> It is the mark of an educated mind to be able to entertain a thought
> without accepting it.
>
> ===================================
> This list is hosted by DevelopMentor(R) http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
>
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
