1

Topic: Dispose interface, Dispose pattern

Good afternoon, I Draw with GDI + and it is necessary on idea to release  after such  as Font, Pen etc.  interface Dispose as here it is written, and something to me not wanted to make a fuss with Dispose Pattern. Made on the simple: public void Dispose () {if (mTitleFont! = null) {mTitleFont. Dispose (); mTitleFont = null;}} ~MyClass () {Dispose ();} It would be desirable to learn, how the people implement interface Dispose.

2

Re: Dispose interface, Dispose pattern

Hello, Iso12, you wrote: I> It would be desirable to learn, how the people implement interface Dispose. The finalizer if it retains only links to managed-objects is not necessary to a class. Moreover, the finalizer is not necessary almost never in the application-oriented code. So in your case of implementation Dispose it is quite enough: public void Dispose () {if (mTitleFont! = null) {mTitleFont. Dispose (); mTitleFont = null;}}

3

Re: Dispose interface, Dispose pattern

Hello, Iso12, you wrote: I> It would be desirable to learn, how the people implement interface Dispose. Before to be started up in reasonings I recommend to read https://www.codeproject.com/Articles/29 … -You-About When it is necessary I write normally so: class XXX: IDisposable {public void Dispose {//Logic of closing//Clearing of resources which the class}} Any finalizers owns. Unmanaged resources never in managed turned, except several demos, therefore and finalizers did not write. PS. It would be necessary to translate article under the link into Russian who for - put a finger upwards to this message.

4

Re: Dispose interface, Dispose pattern

Hello, hardcase, you wrote: H> the finalizer if it retains only links to managed-objects is not necessary to the Class. Moreover, the finalizer is not necessary almost never in the application-oriented code. On how many I understand, if objectOfMyClass. Dispose () it will not be caused, storage will not be released. Therefore I also implemented also the finalizer.

5

Re: Dispose interface, Dispose pattern

Hello, Iso12, you wrote: I> Hello, hardcase, you wrote: H>> the finalizer if it retains only links to managed-objects is not necessary to the Class. Moreover, the finalizer is not necessary almost never in the application-oriented code. I> on how many I understand, if objectOfMyClass. Dispose () it will not be caused, storage will not be released. I will be released I> Therefore and implemented also the finalizer. Just in this case it will not be released. It will more truly be released later.

6

Re: Dispose interface, Dispose pattern

Hello, Iso12, you wrote: I> On how many I understand, if objectOfMyClass. Dispose () it will not be caused, storage will not be released. Therefore I also implemented also the finalizer. We present that Dispose () has not been caused also the object objectOfMyClass became unattainable, then it becomes garbage. And time it became garbage also all objects on which it retained links also became garbage (we consider that these links anywhere more were not copied during lifetime of object). Arguing thus we reach wrappers over  GDI + at which is correct  the finalizer (successors SafeHandle). Their finalizers finally will be caused, and resources will be released.

7

Re: Dispose interface, Dispose pattern

Hello, hardcase, you wrote: H> we Present that Dispose () has not been caused also the object objectOfMyClass became unattainable, then it becomes garbage. And time it became garbage also all objects on which it retained links also became garbage (we consider that these links anywhere more were not copied during lifetime of object). Arguing thus we reach wrappers over  GDI + at which is correct  the finalizer (successors SafeHandle). Their finalizers finally will be caused, and resources will be released. Thanks for the torn answer. Then it turns out that in my case generally it is possible IDispose not . The finalizer from Font object  at destruction of my object and storage will anyway be released. So? Whereas to understand what here  write?

8

Re: Dispose interface, Dispose pattern

Hello, Iso12, you wrote: I> Then it turns out that in my case generally it is possible IDispose not . It turns out that so, but... I> the Finalizer from Font object  at destruction of my object and storage will anyway be released. So?... The finalizer will be caused on the garbage collection following after those when collected your object. Garbage collection in a primitive type looks so: 1) we collect garbage, 2) of garbage objects with finalizers it is done new queue , 3) we cause finalizers from current queue, 4) new queue becomes leaking, I.e. objects with the finalizer generally (if it is not caused SuppressFinalize) endure garbage collection and are final written off in breakage only after  when the finalizer call.  in the image, the moment when release  under your fonts depends on that how much vigorously your program consumes storage. If it at some instant ceases to select storage objects with the finalizer can live before program termination (application domain). P.S. Here it is necessary to mark that any object which has endured garbage collection (and objects in queue on  are that), automatically leaves in following generation, and the the generation - the less often it  GC is higher.

9

Re: Dispose interface, Dispose pattern

Hello, Iso12, you wrote: I> It would be desirable to learn, how the people implement interface Dispose. Difficult Briefly: 1. Call Dispose is postponed until then yet do not complete operation remaining methods of the interface of a class. 2. After passage in a disposed-condition, all interface methods (except Dispose) throw out an exception that-there-with-Disposed. - - Separate hatred to those basic classes which of the Dispose cause the virtual methods.

10

Re: Dispose interface, Dispose pattern

Hello, hardcase, you wrote: I here will generalize that I understood, and you me correct if what not so. 1) If we have only menaged objects with implemented IDispose the interface, it is possible Dispose () in these objects and not to cause. Memory leaks will not be, provided that at this class the finalizer is competently implemented. 2) if Dispose () not to cause that can happen so that not used object can long time or till the end of program performance to occupy storage. 3) if we have in any class we have menaged objects with implemented IDispose the interface (as in my case) to implement the finalizer for this class it is not meaningful, as it removes object removal on the following collection cycle of garbage. It is enough to implement Dispose (), for fast clearing of storage.

11

Re: Dispose interface, Dispose pattern

Hello, Iso12, you wrote: I> Hello, hardcase, you wrote: I> I here will generalize that I understood, and you me correct if what not so. I> 1) If we have only menaged objects with implemented IDispose the interface, it is possible Dispose () in these objects and not to cause. Memory leaks will not be, provided that at this class the finalizer is competently implemented. Generally it is not true. Objects can be signed on any events outside, with the formal reply in Dispose a method, in this case objects will exist before hit in garbage of a source of events. I> 2) if Dispose () not to cause that can happen so that not used object can long time or till the end of program performance to occupy storage. In the presence of the registered finalizer. For example, if to cause method Close at FileStream, it is possible not to cause Dispose, and the finalizer nevertheless will be disconnected. I> 3) If it is had in any class it is had menaged objects with implemented IDispose the interface (as in my case) to implement the finalizer for this class it is not meaningful, as it removes object removal on the following collection cycle of garbage. It is enough to implement Dispose (), for fast clearing of storage. It is correct.

12

Re: Dispose interface, Dispose pattern

Hello, Iso12, you wrote: I> the Finalizer from Font object  at destruction of my object and storage will anyway be released. So? "Anyway" - can be too late. Depends that such yours mTitleFont. Or unmanaged resources - he is obliged to implement a simple rule if the type comprises IDisposable IDisposable. It allows the causing code  to destroy unnecessary  (for example, using using), instead of to rely on GC. For best "mastering" you need to attack once this rake (for example to receive OutOfMemoryException). Dare!

13

Re: Dispose interface, Dispose pattern

Hello, hardcase, you wrote: Thanks!

14

Re: Dispose interface, Dispose pattern

Hello, Iso12, you wrote: All is extreme simple - if you are not assured absolutely,  it is not necessary to write, and pattern Dispose forget as a bad dream. The majority of unmanaged resources already in  is enveloped, and those that are not enveloped to store in standard things of type SafeHandle better. Well and in Dispose simply you cause Dispose all nested objects.... <<RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

15

Re: Dispose interface, Dispose pattern

I> 1) If it is had only menaged objects with implemented IDispose the interface, it is possible Dispose () in these objects and not to cause. Memory leaks will not be, provided that at this class the finalizer is competently implemented. Still the reason, except events. Framework  the finalizer when considers the necessary. It considers volume of the free storage and processor loading. The finalizer can not be caused very long if it is a lot of free storage, and the processor is occupied. If in the finalizer it is released  to a DB or a file the resource will be occupied indefinite time. As consider that the finalizer is caused in a separate flow.

16

Re: Dispose interface, Dispose pattern

Hello, Sinatr, you wrote: S> "Anyway" - can be too late. Depends that such yours mTitleFont. S> or unmanaged resources - he is obliged to implement the Simple rule if the type comprises IDisposable IDisposable. It allows the causing code  to destroy unnecessary  (for example, using using), instead of to rely on GC. S> For best "mastering" you need to attack once this rake (for example to receive OutOfMemoryException). Dare! It is possible an example? How absence of call Dispose can lead OutOfMemoryException? - Yours faithfully, Andir! using (RSDN@Home 1.0.0 alpha 5 rev. 0) {/* It is worked... */}

17

Re: Dispose interface, Dispose pattern

Hello, Andir, you wrote: S>> or unmanaged resources - he is obliged to implement the Simple rule if the type comprises IDisposable IDisposable. It allows the causing code  to destroy unnecessary  (for example, using using), instead of to rely on GC. S>> For best "mastering" you need to attack once this rake (for example to receive OutOfMemoryException). Dare! A> it is possible an example? How absence of call Dispose can lead OutOfMemoryException?  a heap , for example, and at once them to delete. At me so it turned out OutOfMemoryException. Truth on the second .

18

Re: Dispose interface, Dispose pattern

Hello, vmpire, you wrote: A>> It is possible an example? How absence of call Dispose can lead OutOfMemoryException? V> Zaallotsirovat a heap , for example, and at once them to delete. V> at me so it turned out OutOfMemoryException. Truth on the second . -, thanks, clearly. Unmanaged   will not be released while finalizers do not fulfill. Yours faithfully, Andir! using (RSDN@Home 1.0.0 alpha 5 rev. 0) {/* It is worked... */}