On 19 Aug 2011, at 16:00, Chris wrote:
> Hello everybody,
>
> i've some doubt about this code (omissis header and include files)
>
> file: main.cpp
> int main(int argc, char *argv[]) {
>
> int k = 0;
>
> Test *test = new Test();
> k = Fl::run();
> delete test;
>
> return k;
>
> }
>
>
> file: Test.cpp
> Test::Test() {
>
> this->win = new Fl_Window(100, 100, 250, 170);
> this->win->label("TEST");
>
> this->win->begin();
> this->output = new Fl_Multiline_Output(0, 20, 250, 150);
> this->win->end();
>
> this->win->show();
>
> };
>
> Test::~Test() {
>
> Fl::delete_widget(this->win);
>
> };
>
>
> First: is it correct to set the label inside the constructor or is the space
> for "TEST" released at the end of function?
If you are concerned that the label string will go out of scope before the
window terminates, you should probably use
win->copy_label("TEST");
instead, as it will make a "permanent" copy of the string in the widget.
> Second: is it the right way to release win (and it's child) with the call in
> the destructor?
Why do you want to?
In the example given (I concede it is probably a simplification of some more
complex code...) the window lifetime is the same as that of the application, in
which case there's no point explicitly delete'ing it.
Just hide it, then let the program terminate.
Once the program terminates, the OS runtime will recover all the allocated
memory, and will (generally) do so far more efficiently than you can.
You only need to worry about freeing allocated objects that normally expire
during the running of your code, as they may leak *whilst the code is running*.
Widgets whose lifetime is that of the program, well, just let the OS clean up
for you.
The cost of fltk widgets is pretty low - a hidden window doesn't hold on to
very much resource at all, so if you are creating / deleting widgets a lot
during runtime, it may be better to make a bunch of suitable windows then
"repurpose" them on the fly, hiding them between uses, rather than tearing them
right down then creating new ones every time. Worth considering, anyway.
As an aside, I'd have derived the Test class from Fl_Window, rather than making
the window be a member of the class - that generally makes it simpler to manage
the derived window behaviours - though YMMV of course...
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
