On 30.05.2012 04:26, David Currie wrote:
> Consider the following,
...
> disp->buffer(tbuff);
> printf("...Run...\n");
> Fl::run();
> // disp->buffer(NULL);
> printf("Deleting sbuff..."); delete sbuff;
> printf("Deleting tbuff..."); delete tbuff;
Here you delete tbuff that is still associated with disp, if you
leave the comment. This is wrong.
> Just run this pressing ESCAPE 3 times. Observe the output
>
> win = 0x93f0008 disp = 0x93f00b0 tbuff = 0x93f0350 sbuff = 0x93f07c0...Run...
> Fl_Text_Buffer::remove_modify_callback(): Can't find modify CB to remove
> Fl_Text_Buffer::remove_predelete_callback(): Can't find pre-delete CB to
> remove
> Deleting sbuff...Deleting tbuff...Deleting disp...Deleting win...DONE
...
> Some Questions , First if you UNcomment disp->buffer(NULL),
> the 2 lines below disappear.
> Fl_Text_Buffer::remove_modify_callback(): Can't find modify CB to remove
> Fl_Text_Buffer::remove_predelete_callback(): Can't find pre-delete CB to
> remove
>
> Why is this so? Why SHOULD this be so?
See above. You MUST tell the Fl_Text_Display widget that you're going to
delete its associated text buffer, otherwise it will access deleted
widget memory, and that is causing (at best) undefined behavior.
> Secondly, each example that I have seen has ONLY 1 window(++...).
> This code makes a window(++widgets) appear AND disappear.
> I would assume that it should clean up after itself CLEANLY (memory wise).
Yes, it will, there shouldn't be problems with this
>
> It seems to me theoretically that each
>
> win = 0x93f0008 disp = 0x93f00b0 tbuff = 0x93f0350 sbuff = 0x93f07c0...Run...
> win = 0x93f0008 disp = 0x93f00b0 tbuff = 0x93f07c0 sbuff = 0x93f0350...Run...
> win = 0x947c308 disp = 0x947c3b0 tbuff = 0x93f0350 sbuff = 0x93f07c0...Run...
>
> should have the SAME VALUES.
Not necessarily - see what Greg wrote about this.
> Note this is just one PARTICULAR example of (Widget pollenation).
I don't understand "Widget pollenation". Could you explain what you
mean?
> Has every widget been checked for memory leakage/fragmentation ?
> Automatically.
There are always people who check FLTK with valgrind or other tools,
and usually there are no memory leaks reported. There may however be
some global variable/buffers allocated during runtime that are never
deallocated/freed. However, this doesn't matter, since this memory
will be freed at the program's exit.
> Perhaps there is something I have missed.
Maybe. If you are really concerned about memory leaks, run a FLTK
program with valgrind or similar tools, and see what it reports.
Only growing memory usage during normal program execution should
be considered problematic. Your program is a good test, and it
should NOT show memory leaks.
Note also that "Deleting disp..." (delete disp;) also removes it
from its parent group (the window), and this is not necessary, since
deleting the window would also delete disp. It's usually better to
leave this to FLTK than to try to do it all correctly.
Albrecht
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
