From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-08-01 13:56:47
> 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
I think that it is very likely. For examle you can
overload only a subset of functions in the standard
PhysicalGuiLayer class. For example if there is a
Win32 PhysicalGuiLayer, you could overload only
several functions to customize the standard edit
control functions. And guess what... you have a new
GUI layer with a custom edit contorl.
> 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
No exactly, the PhysicalGuiLayer class itself will
have only a hundred or so function declaraions and in
general it won't be a template. Including a hundred or
so functions declaration is not a big deal. When you
include windows.h, you are compiling thousands of them
> 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.
I don't like the pImpl idiom at all. The flexibility
that the Impl template parameter (ImplTempl) gives me
is much more compeling to me than saving a tiny bit of
the compilation time with pImpl.
In the case of the boost::threads library, I would do
something like this.
template< typename Impl = win32ThreadTraits >
This way you could customize the Impl parameter to use
Win32 fibers instead of normal threads.
It'll be something like following
calss win32FiberTraits : public win32ThreadTraits
//overload some functions to support fibers
It is much more beatiful, than hiding everything in
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk