From: "E. Gladyshev" <[EMAIL PROTECTED]> [snip] > template < typename IT, typename PhysicalGuiLayer > > class ListControl [snip]
I'm coming in a bit late into this discussion, but I too am interested in the outcome of this project. I strongly dislike the PhysicalGuiLayer template parameter, for several reasons: 1) It buys us very little: generally template parameters are useful when more than one instantiation will be used within any particular program. It is highly unlikely that a program will support two physical GUI layers simultaneously, and I would claim that any such program would be such a usability nightmare as to be excluded from consideration. 2) It hurts us a lot: compile times will skyrocket because every widget, layout engine, etc. will have to have full source code included in every translation unit. We cannot do this to users, especially with a GUI library, because GUIs are often tweaked (requiring many builds). 3) There is an alternative solution: Boost.Threads presents a single, non-template interface to the user and hides all of the platform-specific details using the pImpl idiom. The same approach can be applied here, and I think we'll find that it has all of the same advantages. Here is a more general comment regarding the compile-time vs. run-time discussions: Genericity can be accomplished at run-time or at compile-time, but neither approach excludes the other. I believe that one bit that falls out of the above agrees 100% with the poster that suggested the following: class list_control; // implemented by the library. Uses some sort of generic "list element" type template<typename Element> class typed_list_control; // thin wrapper over list_control. "Element" is the type of the data in the list As noted earlier, this design has a huge number of benefits: 1) list_control is not a template, so we can use the simplified cross-platform model used in Boost.Threads, and of course this gives us the ability to create a much more dynamic system (e.g., loaded from a resource file) if we choose to. 2) typed_list_control gives us all of the great static-checking features we would want, but in a lightweight veneer. I've used this model extensively before (e.g., Boost.Signals uses it to shrink the size of boost::signal template instantiations), and it has worked very well. Doug _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost