Bill Spitzak wrote:
>
> FLTK 2 has an attempt to solve this that uses *no* fields in the widget.
This was my intention too - I wanted to use just 1 bit within flags
which would indicate to call *THE SAME* callback when the widget dies,
but this time with NULL as the widget argument (which is partially
destructed anyway) so
widget->callback(&my_callback, callback_data);
widget->set_flag(DESTRUCT_CALLBACK);
and then the user can do
void my_callback(Fl_Widget * w, void * data){
if(w)
((Callback_Class *)data)->call();
else
delete (Callback_Class *)data;
}
would do the trick without the need to have a hash table or special
associated classes with virtual destructor or associated destruction
function for these animals. This could be left up to the user and maybe
some add-on library.
> associate data with the widgets. ~Widget will call a destructor on all
Yeah, that would translate to
Fl_WIdget::~Fl_Widget(){
...
if(callback_ && (flags() & DESTRUCRED_CALLBACK))
(*callback_)(0, data_);
}
in the example above.
> Instead it uses a hash table indexed by widget pointer + data class to
OFF TOPIC:
I have a mixed feeling about hash tables. I used them only on a few
occasions when I knew the number of items exceeds some thousand(s) or
so. The overhead depends on implementation, I did some "unprofessional"
testing with simple ones with several bytes of both fixed and variable
key length (including similar to the one in fltk src) and it seems to me
that direct, flat comparison is usually faster than hashing at least up
to several hundred items in the table (and you save some memory space
and code too). I did not test b-trees etc which are more complicated and
seems to be better suited for even bigger sets where the length varies a
lot.
R.
_______________________________________________
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
