Author Topic: ResultBuffer why don't Dispose it ?  (Read 2507 times)

0 Members and 1 Guest are viewing this topic.

bikelink

  • Guest
ResultBuffer why don't Dispose it ?
« 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() ?
}

Glenn R

  • Guest
Re: ResultBuffer why don't Dispose it ?
« Reply #1 on: February 28, 2009, 01:57:36 PM »
Wrap it in a 'using' and job done, but yes, you should dispose of it.

It's Alive!

  • Retired
  • Needs a day job
  • Posts: 8661
  • AKA Daniel
Re: ResultBuffer why don't Dispose it ?
« Reply #2 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.

bikelink

  • Guest
Re: ResultBuffer why don't Dispose it ?
« Reply #3 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.

TonyT

  • Guest
Re: ResultBuffer why don't Dispose it ?
« Reply #4 on: March 03, 2009, 05:40:49 PM »
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).