Matthias wrote: > OMHO this is wrong. The template is just a different implementation of > #define and creates new implementations for every template that you call.
Can you suggest an other conception of using the templates ? If yes, I think you should explain it to Mr. Stroustrup ;-) > Tons of code doubling and trippling and a horror to debug. That is not so awful as it seems. > In this particular case, it would be much simpler to add the highlighting > feature to Fl_Button, so all derived button types would benefit from it. > Since the library is OpenSource, this is a breeze to do and benefits widgets > that you may add long after you have forgotten about this particular template. I can't agree with you. This is a case of a pure generic programming. The particular example is clear, convenient in using and applicable almost to any widget. In fact I write down this template straight into the class field of FLUID and have no problem. And my classes don't depend on the current release of FLTK. If I decided to do it by your 'much simpler' way, it would be necessary to change a few base classes, debug inner things of FLTK, merge the changes with every new release of the library and be afraid of some critical improvements from the FLTK team. And of course one day I'll forget to do patching. What will happen then with my project ? (In fact I had had all these "pleasures" with the port FLTK-DFB.) No, I prefer saving my time and my mind to get some profit of several bytes after compiling. Our C++ (and the others modern programming languages) was invented to help developers but not generate the more compact binary code... _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
