Many things to say.
Firstly (Albrecht) widget pollenation = the set of all Widgets + child Widgets
+ operations (add/resize/delete/etc). I used the term in it's context because I
was concerned whether FLTK would ALWAYS (generically) CLEAN it's own memory.
Also, I have already guessed FWIW = for what it's worth STR = software trouble
report,
AFAICT = as far as I can tell, FRE = ???
>exit()ing a program calls all destructors first before exiting.
I didn't know this although I can't see how (unless C++ runtime has an
internal destructor list??).
> _exit()ing a program does NOT call the destructors,
> but memory is still freed altogether in one big chunk.
Certainly.
Now , according to what I understand of C++, and indeed OOP in general
If class C has a destructor ~C() and you say
C* c = new C();
..
delete c; // C++ calls c->~C() to first destroy c then calls free(c) to release
the memory;
Of course if c is a (stack) object (and not a pointer) and goes out of context
C++ will call ~C() (using its stack address) to destroy c but will NOT call
free().
I can certainly ACCEPT the FLTK Style (keeping track internally of FL objects)
But I would consider this UNUSUAL because when writing C++
A* a = new A();
B* b = new B();
C* c = new C();
a.end();
..
//delete c; // should be allowed to do this
//delete b; // should be allowed to do this
delete a;
The very language itself is more than a memory management philosophy,it is a
(defined) ENTITLEMENT.
Now,it has been asserted when FL::run() returns, the window is closed (hidden)
but not destroyed.
I have done some iterative testing using valgrind
#include <FL/Fl.H>
#include <FL/Fl_Window.H>
int main() {
int lW = 640; int lH = 480; int lCount = 3;
while (lCount--)
{
Fl_Window* lWind = new Fl_Window(lW,lH,"Window");
lWind->end();
lWind->show(); // this line causes heap to go out
delete lWind;
}
return(0);
}
Valgrind output is
==7106== Memcheck, a memory error detector
==7106== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==7106== Using Valgrind-3.6.1-Debian and LibVEX; rerun with -h for copyright
info
==7106== Command: test/demo
==7106==
==7106==
==7106== HEAP SUMMARY:
==7106== in use at exit: 440,808 bytes in 1,080 blocks
==7106== total heap usage: 12,136 allocs, 11,056 frees, 1,723,686 bytes
allocated
==7106==
==7106== LEAK SUMMARY:
==7106== definitely lost: 132 bytes in 2 blocks
==7106== indirectly lost: 29 bytes in 1 blocks
==7106== possibly lost: 0 bytes in 0 blocks
==7106== still reachable: 440,647 bytes in 1,077 blocks
==7106== suppressed: 0 bytes in 0 blocks
==7106== Rerun with --leak-check=full to see details of leaked memory
==7106==
==7106== For counts of detected and suppressed errors, rerun with: -v
==7106== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 48 from 9)
I don't know how to interpret these results. Does the ERROR SUMMARY imply NO
problems
or does the LEAK SUMMARY imply PROBLEMS. I wish to test further so please
ADVISE.
(Note I have seen evidence there are definite leaks elsewhere)
Sadly to admit, I have been "creating and deleting windows over and over again"
in order to (trial and error) calculate the maximum TextX, TextY for a given
(FL_COURIER)font that will fit EXACTLY to 1 screen.
Obviously this should be precoded using (some) combination of components
( Fl::w(),Fl::h(),Fl::screen_xywh(X,Y,W,H),
Fl_Text_Display::col_to_x(double col), Fl_Text_Display::position_to_xy(int
pos,int* x,int* y) ).
I haven't figured out a workable method yet without first putting a display
hence the idea of allowing the user to set their own sizes
by "creating and deleting windows over and over again"
So If someone knows how to
void getMaxWHXY(int& pW,int& pH,int& pX,int& pY,int pFont)
// given (FL_COURIER) pFont, calculate pW,pH,pX,pY
// pW = maxPixelWidth pH = maxPixelHeight pX = maxTextWidth pY = maxTextHeight
I won't really need to "create and delete windows over and over again".
That said, I still consider this worthy of investigation for the sake of
completeness.
I would assume most FLTK users just have one Window(++Widgets...) + lots of
callbacks()
+ Fl::run() then exit().
Maybe this is why no-one has noticed any leaks as they always go out in the
wash.
As usual I am just one punter looking for a result. But I am prepared to
examine this if allowed.
Advice?
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
