Willem Kokke
10/27/2002 1:03:00 AM
then you still didn't get my point.
ms-help://MS.VSCC/MS.MSDNVS/cpguide/html/cpconimplementingdisposemethod.htm
By implementing the standard disposing pattern like this, you guarantee that
the unmanaged resources are released sometime after the last reference went
out of scope.
public class UnmanagedWrapper
{
public UnmamagedWrapper()
{
AllocateUnmanagedResources();
}
public void Dispose()
{
Dispose(true);
}
private Dispode(bool disposing)
{
if (disposing)
{
GC.SuppressFinalize(this);
}
ReleaseUnmanagedResources();
}
~UnmanagedWrapper()
{
Dispose(false);
}
}
now if you have a static constructor like this, you guarantee that the
unmanaged resources are there before the first static method gets invoked,
and that they will be deleted at the programs end (since the finalizer of
the UnmanagedResources class will be called then
public class StaticClass
{
private static myUnmanagedResources;
static StaticClass()
{
myUnmanagedResources = new UnmanagedResources();
}
}
I agree that a static destructor would be a logical feature, there is none,
propably for some good reason.. this is an easy way to solve the problem
nontheless
HTH,
Willem
in that static constru
"Rodney S. Foley" <aalst@aalst.com> wrote in message
news:OVr1AXUfCHA.4228@tkmsftngp08...
> Easy to say not easy to do.
>
> There are reasons for static constructors, and sometimes you have no
choice
> but to access unmanaged code in them. I am in this situation. So telling
> me not to do something I have no choice to do is not helpful. I should
not
> have to explain my situation, since my request provide all the information
> needed, but I will.
>
> My class does not get instantiated, it is full of nothing but static
methods
> that wrap unmanaged C functions. There is stuff that has to be done
before
> calling one of those static methods, so this has to be done in a static
> constructor. This is one of the purposes of a static constructor. If I
> could have done this stuff in a normal constructor I would be doing this.
>
> If Microsoft would provide a 'logical' way for me to follow the rule you
> specified, then I would be doing it that way, and I would never had posted
> anything about this.
>
> Thanks,
>
> Rodney
>
>
> "Willem Kokke" <w.kokke@dion-software.com> wrote in message
> news:esfruFUfCHA.1816@tkmsftngp12...
> > I'm not sure why they're not there, but there's a easy solution..
> >
> > never aquire unmanaged resources directly in a static constructor.
> >
> > if you simply follow the rule that all unmanaged resources should be
> > aquiered and released in a class, that implements dispose and a
finalizer
> > that calls dispose if it isn't called yet, the need for static
destructors
> > is gone..
> >
> > instead of aquiering the unmanaged resources, you simply instatiate the
> > managed class, which will take care of releasing the resources
themselves
> > through the finalizer..
> >
> > HTH,
> > Willem
> >
> > "Rodney S. Foley" <aalst@aalst.com> wrote in message
> > news:#86CsfTfCHA.2440@tkmsftngp08...
> > > Why would Microsoft allow a Static Constructor, but not allow a Static
> > > Destructor?
> > >
> > > If you construct something, wouldn't it be nice to be able to destruct
> it
> > > regardless of if it was constructed statically?? Especially if you
are
> > > dealing with unmanaged items in a static constructor, it would be nice
> to
> > > tell the unmanaged code that you are done with it's stuff. :) So
what
> > > happened to Classes that did some static stuff with unmanaged code in
a
> > > static constructor when the application is closed? The unmanaged code
> > seems
> > > to be leaving this stuff out there. Not allow a static destructor
seems
> > to
> > > allow for memory leaks possibilities. Is there another solution that
> can
> > do
> > > the same thing as a static destructor that would ONLY be called
> > > AUTOMATICALLY once the application is closed.
> > >
> > > Anyone at Microsoft have a "Good" reason why it was left out? And do
> they
> > > plan on adding it to a future release?
> > >
> >
> >
>
>