gga wrote: > > FLTK's design allows it to also avoid dynamic casting, which is a minor > benefit.
OK, I have no counter argument to this benefit. This does make the trouble of possible error conditions, forgetting begin() or end(), acceptable. And the direct use of p->add( child ) helps keep the code clear. > > Note also that matthias' example did not use pointers at all, but > instantiated the elements of a composite widget within the class itself, > making the class "fatter" if initialized on the stack but the code much > cleaner inside the class (no pointer math) and a tad smaller when used > with new. The removal of pointer math seems to be main advantage, and I'll admit it's a big one. > Threading issues are indeed a concern, but since, afaik, all OS gui > toolkits are not really thread safe, fltk's approach is currently not > creating any additional issues. And here I thought fltk was thread safe? -Daniel _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
