<tdalign="right"valign="center"><imgsrc="logo32.png"align="right"width="64"height="32"border="0"></td></tr></table><h1align=center>Why doesn't TQt use templates for signals and slots?</h1>
<p> A simple answer is that when TQt was designed, it was not possible to
fully exploit the template mechanism in multi-platform applications due
to the inadequacies of various compilers. Even today, many widely used
C++ compilers have problems with advanced templates. For example, you
cannot safely rely on partial template instantiation, which is essential
for some non-trivial problem domains. Thus TQt's usage of templates has
to be rather conservative. Keep in mind that TQt is a multi-platform
toolkit, and progress on the Linux/g++ platform does not necessarily
improve the situation elsewhere.
<p> Eventually those compilers with weak template implementations will
improve. But even if all our users had access to a fully standards
compliant modern C++ compiler with excellent template support, we would
not abandon the string-based approach used by our <ahref="metaobjects.html#meta-object">meta object</a> compiler.
Here are five reasons why:
<p><h3>1. Syntax matters</h3>
<p> Syntax isn't just sugar: the syntax we use to express our algorithms can
significantly affect the readability and maintainability of our code.
The syntax used for TQt's signals and slots has proved very successful in
practice. The syntax is intuitive, simple to use and easy to read.
People learning TQt find the syntax helps them understand and utilize the
signals and slots concept -- despite its highly abstract and generic
nature. Furthermore, declaring signals in class definitions ensures that
the signals are protected in the sense of protected C++ member
functions. This helps programmers get their design right from the very
beginning, without even having to think about design patterns.
<p><h3>2. Precompilers are good</h3>
<p> TQt's <tt><ahref="moc.html#moc">moc</a></tt> (Meta Object Compiler) provides a clean way to go
beyond the compiled language's facilities. It does so by generating
additional C++ code which can be compiled by any standard C++ compiler.
The <tt>moc</tt> reads C++ source files. If it finds one or more class
declarations that contain the "Q_OBJECT" macro, it produces another C++
source file which contains the meta object code for those classes. The
C++ source file generated by the <tt>moc</tt> must be compiled and
linked with the implementation of the class (or it can be
<tt>#included</tt> into the class's source file). Typically <tt>moc</tt>
is not called manually, but automatically by the build system, so it
