TheSwamp

Code Red => .NET => Topic started by: bikelink on February 28, 2009, 06:41:01 AM

Title: ResultBuffer why don't Dispose it ?
Post by: bikelink on February 28, 2009, 06:41:01 AM

Hi, just a quick question.
c#

voidf myf()
{
ResultBuffer pRb = new ResultBuffer();
blabla....


pRb must be disposed() ?
}

Title: Re: ResultBuffer why don't Dispose it ?
Post by: Glenn R on February 28, 2009, 01:57:36 PM

Wrap it in a 'using' and job done, but yes, you should dispose of it.

Title: Re: ResultBuffer why don't Dispose it ?
Post by: It's Alive! on February 28, 2009, 06:33:42 PM

Calling Dispose on a ResultBuffer, deletes the underlying resbuf by calling the native ARX function acutRelRb. 
As in native ARX, there are times where you would want to free the resources and times where you wouldn’t.

Title: Re: ResultBuffer why don't Dispose it ?
Post by: bikelink on March 03, 2009, 03:33:17 PM

Thank You Daniel. Your suggest was good.
I had a resbuf of an xdata unreleased...and sometime autocad crashed.

Title: Re: ResultBuffer why don't Dispose it ?
Post by: TonyT on March 03, 2009, 05:40:49 PM

Quote from: bikelink on February 28, 2009, 06:41:01 AM

Hi, just a quick question.
c#

voidf myf()
{
ResultBuffer pRb = new ResultBuffer();
blabla....


pRb must be disposed() ?
}

Technically, no it doesn't have to be disposed.

It can be, and probably should be especially if
it's large, but if you don't do it, the unmanaged
resources (the resbuf chain) is deleted when the
instance is finalized by the GC.

Since everything that can appear in a ResultBuffer
is thread-safe, there's no danger from allowing it
to be finalized.

The same holds true for many other objects in the
managed api (like for example, ObjectIdCollection).
The unmanaged data they delete when they're
disposed can be deleted in any thread, so there's
no problem with allowing them to be finalized.

The reason why so many managed API objects that
do not have to be determinstically disposed implement
IDisposable, is largely one of convenience (and in my
opinion, crappy API design), by virtue of their common
ancestor (DisposableWrapper).