> > > > void callback( void (*)(Widget*, void*), void* ); > > > > is a very old C-style pattern. > > It is nothing wrong with this "very old C" style ... if it is flexible
I agree it is not terrible but you can't say there is "nothing" wrong with it. There is at least one thing wrong with it, it uses a void* so is not type safe. > I agree that typesafety and flexibility is the goal, but I think it does > not need to be a part of Fl_Widget class. You don't think type safety and flexibility should be part of the Fl_Widget class??!! If so that does rather end the discussion. Are you sure you meant to say it like that? > Having callback structure > "outside" the widget has a few advantages, like callback lifetime > management. Suppose widget A calls some object B method. Who should be > responsible for removal of calback (in other words to whom it should > belong), A or B? Preferably both and callback should be removed by the > first who dies, ie if it is B it must inform A not to call it amymore. > Also attaching callbacks to non-widget objects, making callback chain or > tree propagation is easier. > Yes, all very good points. As you mention below things like libsigc++ and boost::signal look at these problems. I'm not an expert on these libraries but don't they sit between the signal producer and receiver "managing" the connection, but regardless still expect the signal producer to be something that wants to call into a functor, which Fl_Widget doesn't. > > > suggested. From this perspective Fl_Signal is just a fix to this C-Style > > part of the, what should be a C++, API. > > and > > > idealistic than practical i.e. what would the perfect FLTK C++ API look > > like wrt setting up callbacks? > > I was looking to various callback systems: libsigc++, boost::singal, QT > signal/slot stuff and was not too much happy with any of them... > > I see that good system should: > ... Fl_Signal does look very good. Will it be a standard part of the FLTK library from v2 onwards? As a C++ programmer though, I still have alarm bells ringing when I see a void* in a C++ library API. Yes, sometimes there is no way round it. Is this such a case? > > > > void callback(shared_ptr<Receiver> r); > > > > I do not think we want to use std template library too much because then > you need to link to libstdc++ : I always compile c++ code with "gcc" and > not "g++" to avoid linking to that beast (but this my be only my > personal detaste with stdc++ - rather writing my own templates) > > One more thing: you said that templates are supported well with recent > compilers. This is only partially true: When I was witting it (a few > ears ago), I was trying to use not very advanced template functionality > bud still had to go around many bugs in their implementations. And I was > testing it only with gcc and MS visual studio! As you said, you did this test a few years ago. The C++ 98 standard has been out for over 10 years now. If people are still using compilers that can't compile the kind of template code you have in Fl_Signal I would be a little surprised. You only have to look at the kind of coverage boost has with compilers released in recent years to appreciate how good template coverage is. > So I think we should avoid the use of templates in fltk core at any cost. > If you did put template code in the fltk core and a user came back and said the compiler did not handle it I think today you would be pretty justified in telling them to get a standard conforming compiler, there are lots out there including free ones. Personal opinion of course. All I was actually saying is that the Widget::callback API is not type safe and could one come up with a better API. I think if one rules out using templates then the answer is no. This is fine, as I said, it's not bad. Mike. _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
