From: Douglas Gregor (gregod_at_[hidden])
Date: 2003-08-01 01:39:49
From: "E. Gladyshev" <egladysh_at_[hidden]>
> template < typename IT, typename PhysicalGuiLayer >
> class ListControl
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
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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk