Re: [boost] GUI/GDI template library

From: Douglas Gregor (gregod_at_[hidden])
Date: 2003-08-01 01:39:49

From: "E. Gladyshev" <egladysh_at_[hidden]>
[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