|
Tip #7 - Clean up after yourself!
As most non-trivial applications require, you've probably found yourself creating secondary forms when designing your applications. And you've probably discovered, based on my first article, that this is very easy to do with Power++. However, there is a hard lesson to be learned by most programmers (including myself) when trying to dismiss these secondary forms. The situation is this: your parent form creates a new modeless form using the new operator and the Create method. The parent form then continues on its merry way, and the secondary form is left to its own devices. The code might look like this:
Form2 * f2 = new Form2; f2->Create( this );After the secondary form performs some operations, it is ready to close itself. The crux is that using the Close method does not free all of the resources associated with the form; it only frees resources that were allocated using the Create method, not those allocated when using the new operator. Without some additional effort, however, the secondary form has no way of notifying its parent that it is done and that the parent should perform a delete on it. Thus most programmers assume that Close performs all necessary cleanup; this leads to some rather major memory leaks if secondary forms are opened frequently. For those of you who know C++ relatively well, you also know that using delete( this ) is an unacceptable alternative, as it may interfere with event handles, and also causes execution of the method that called the delete operator while the memory associated with the method has already been deleted.
In anticipation of this problem, Power++ includes functionality to make the task of memory cleanup much easier. In the WApplication class is a method called RegisterDeleteObject. This method will take a WObject argument, and slate the object to be deleted at a time when it is safe to do so. Thus, we can easily add the method call to the Close event of the form. The code might look like that at right.
Please note that the RegisterDeleteObject call must be in the Close event of the form for Power++ version 1.5. If you call this method after the Close event has executed, you will get a page fault. RegisterDeleteObject method has be enhanced for version 2.0 so that it may be called from anywhere safely.
To see this in action, you can choose the View|Debug Log from the main Power++ window, and then choose View|Options to see the available debug options. This window appears at left. By selecting the second option, we can have a summary of allocated and freed memory at the termination of the application. There are other options related to debugging and tracing, and can be seen. The first option will check to see if any memory within the application is overwritten (outside of the application will cause a Page Fault), the third option is for more detailed memory allocation examination, as is the fourth.
The graphic at right is the output of the debug log after the application has terminated. It is an example of the type of memory leak that might occur without the RegisterDeleteObject call in the Close event of the form. Five forms were allocated, then removed with the Close event only - this is why there is a smaller number of deallocations than allocations, indicating unreleased memory. In this example, we can see that 12K remains unfreed; the form that was created was very basic - more complicated forms with more controls and resources associated with them will leave a much greater amount unfreed.
On the left we have the same program with the necessary call to RegisterDeleteObject in the Close event of the form. You can see that the numbers are now as they should be - there are the same number of deallocations as there are allocations, and the same applies to the number of bytes.
Click here to see Tip#8Return to Power++ Home Page.
to top of page
Copyright © 1999 Sybase, Inc. All Rights Reserved.
Privacy Policy
Legal
