| Index > Lgi > Memory (de)allocation in LGI | |
|---|---|
| Author/Date | Memory (de)allocation in LGI |
| Frank De prins 11/01/2003 6:11am | Hello again,
Last week, I was inspecting the memory requirements of a tiny application I made with LGI. I did this using Windows NT4.0 Task Manager. To my astonishment, every time I created a window, some memory was taken up (so far this is normal, of course), but it was not released again when closing the window. Some more information: the window contains a GList which is filled up with items when the window opens. But even without this GList, there is a leak noticable. The most amazing thing is that, even when I explicitly issue an 'empty()' call on this GList and a delete on the window itself, this leak remains. Since I do not see this behaviour in your applications, I am sure I am doing something wrong. Can you tell me please what the normal procedure is to allocate objects in Lgi, who is responsible for deleting them and how they should be deleted (I noticed there is a DeleteObj function). I was using Lgi 1.60 for these tests on Windows NT4/sp6a and compiled the whole stuff with Borland C++ Builder 5.0. Another test with the same EXE (and Lgi) built with MSVC 6.0/sp6 had the same behaviour. In both cases, the executables were built with Debug Info. Best regards Frank De prins Antwerp/ Belgium |
| fReT 12/01/2003 8:16pm | Too some degree this happens with my apps too. The amounts are not large but memory doesn't return to the orginal value when the window closes.
Although to be honest, windows taskmanager is a very inaccurate way of measuring memory usage. And implementations of heaps may hold on to blocks of memory even though they were freed by the program, to be reused down the track. I take the task manager figures with several buckets of salt, they seem to take into account lots of things that aren't really being used by the program and miss other things. There is quite a bit of information on the web about it, and also on how to judge a programs memory usage accurately. Ontop of that there may be leaks in the code. |
| fReT 12/01/2003 10:06pm | I ran Scribe through the memory tracker built into LGI that tracks all new's and delete's. And Apart from pulling up some things in Scribe itself (which I fixed) there is no leaks on the GWindow's or GView's for just openning a window and closing it.
So I put it down to task manager inaccuracies. YMMV :) |
| fReT 12/01/2003 10:18pm | Normally objects have to own the memory pointed to by their member variables. So if you pass a string into an object, for the most part it will take a copy of it if it needs to store it. This applies to simple types like strings, the rule is relaxed when it comes to things like other GViews etc.
A GWindow will generally delete itself when the user closes that window. GView's are generally deleted by their parent's destructor thus cleaning up the whole window heirachy. I use the NEW(...) and DeleteObj/DeleteArray(...) macros for most dynamic allocation. This is to allow the memory manager step in a keep track of things if I want it to. Most of the time they map straight to new/delete/delete[]. For programmatically closing a window use the Quit() function. Although delete'ing it seem to work as well. You can put GDialog's on the stack if you want. Thus not requiring clean up. Although with modeless dialogs you will need to dynamically allocate and destroy them. Dialogs don't delete themselves when the user closes them. This is because of the ability to put them on the stack and also most programs when to retreive information from the dialog after it's closed. Ie to see what the user did. If you still need help just ask. |
| Reply | |