True, templatizing the entire Widget class would cause code bloat which is why
one would be mad to do it. It is possible to implement the template m/f I
suggested without templatizing the whole widget class. For example:
class Widget
{
..
struct BaseData {
virtual void call(Widget*) = 0;
};
template <class F>
struct CbData : BaseData {
F& f_;
CbData(F& f) : f_(f) {}
void call(Fl_Widget* w) {f_(w);}
};
BaseData* cb_functor;
public:
template<class F>
void callback(F& f) {
cb_functor = new CbData<F>(f);
}
};
To call the users function, Widget would use cb_functor->call(this). Only the
template code above would get instantiated if the user called the template
callback m/f and I think you can see that this template code is tiny.
As I said, once you have this single m/f for setting up a callback to a functor
you can then effectively call any function or m/f with any signature using
binding. Simple.
Mike.
>
> Other unrelated option:
> "bloated" widget class with templated calback functions.
>
> This obviously should not be a part of the fltk library but I leave this
> template as an example for the "reach callback" possibility with
> templated widget and special My_Callback functor class:
>
>
> ------------------------------------------------------
>
> template <typename WIDGET>
> class Fl_Callback_Widget: public WIDGET{
>
> bool is_my_callback;
>
> void delete_previous_callback(){
> if(is_my_callback){
> delete ((My_Callback *)user_data());
> is_my_callback = 0;
> }
> }
>
> public:
> template <typename T1, ....>
> void callback(T1 t1, ...){
> delete_previous_callback()
> Fl_Widget::callback(&my_special_callback_function,
> new My_Callback(t1, ....));
>
> ~Fl_Callback_Widget(){
> delete_previous_callback();
> }
>
> // other temples for callback functions
> // ie with different numbers of parameters
> ...
>
>
>
> // All possible constructors with all possible number of parameters:
>
> Fl_Callback_Widget():WIDGET(), is_my_callback(0){}
>
> template <typename T1>
> Fl_Callback_Widget(T1 t1):WIDGET(t1), is_my_callback(0){}
>
> template <typename T1, typename T2>
> Fl_Callback_Widget(T1 t1, T2 t2):WIDGET(t1, t2), is_my_callback(0){}
>
> template <typename T1, typename T2, typemname T3>
> Fl_Callback_Widget(T1 t1,T2 t2,T3 t3):
> WIDGET(t1,t2,t2), is_my_callback(0){}
>
> // ... and so on to - say 7 parameters
> // to accomodate for all possible widget constructors
>
>
> }
>
> // Single special callback for My_Callback functors:
>
> void my_callback(Fl_Widget * w, void * data){
> (My_Callback *)
> }
>
> --------------------------------------------------------------
>
> The advantage of this solution is tat it is an add-on (no changes to the
> library) and you can use this template like ANY other widget but you
> have this extra reach callback system:
>
> Fl_Callback_Widget<Fl_Browser> browser(x, y, w, h, "My browser");
> browser.callback(some_class,&Some_Class::method,argument_value_pointer);
>
> The disadvantage is bloat - for each used widget class there is new
> specialization of the template class.
>
> R.
_______________________________________________
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
