> > > 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. > > > > An extremely simple way to accomplish this goal is to make > Fl_Widget::do_callback() a virtual method. Derived classes > could then implement their own (presumably) type safe callbacks, > or use functors, or do anything else. > > The down side is that one would have to subclass in order to > obtain type safety in callbacks; that wouldn't be an issue for me, > since I use un-subclassed Widgets approximately never, but it may > well be one for others. > > I should note that I'm a big fan of templates, and agree that > use of a standard conforming compiler is a reasonable requirement. > I just don't think that sort of solution is necessary in this case. > > Best, > Stan >
If you look over the history of C++, starting back in the early nineties, the "fashion" was lots of subclassing which created deep hierarchies. With time people learnt the painful consequences of this. It may have been easy for the original developer(s) to create and maintain these deep hierarchies but for new people to come in and debug and maintain these systems it was extremely difficult, especially if the original developers were no longer around. That aside subclassing has a couple more dangers. First, it can create problems with writing strong exception safe code. Even if FLTK itself does not generate exceptions (pretty tricky to do, you would have to avoid "new" expressions for example) it has callbacks into outside code which can generate exceptions, so exceptions will pass through FLTK library, which means its code should be written with strong exception safety in mind. Second, subclassing is "type intrusive". In this case the FLTK types have intruded on your types. This can cause problems, for example, in large systems where you may be using several external C++ libraries. If you are subclassing to connect into these libraries you can start to get name clashes which then becomes messy to code around. That is why in recent years the "fashion" has become shallow hierarchies (only subclassing when you have a true "is-a" releationship) with more use of composition/aggregation and template code. All that said, I see absolutely no reason not to make do_callback virtual. What's the downside? Speed is not an issue in this area. It gives the user flexibility with no degradation of the FLTK code. Mike. _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
