Pau Garcia i Quiles wrote:
> Enforcing OOP everywhere is a good C++ practice. OOP is the central
> point of C++, in case you've forgotten.
Enforcing OOP everywhere is just plain wrong. Some problems can be
solved using OOP, others using functional techniques, and there is also
generic programming. As others pointed out, C++ is multiparadigmatic.
> No support for templates? Are you joking? QList, QVector, etc are all
> template-based classes!
Try this:
template < typename T >
class foo
{
Q_OBJECT
public:
foo();
public slots:
void my_slot();
};
It doesn't work. Also, QList, QVector etc. are irritating. Why copy the
STL in the first place?
Speaking as a programmer who uses Qt 4 daily, I do think it is an
excellent UI toolkit with amazing documentation and RAD tools, but it is
NOT a shiny hammer for everything. I use both Qt4 and Boost, and try to
isolate the Qt4 parts, precisely because the Qt stuff is very invasive.
I also prefer boost.signals over Qt signals because they allow
connecting to ordinary functions (that is, anything can be a slot) and
in fact just expect a function object. This allows for lambda
expressions as well (hint: lambda is not an OOP feature, and *extremely*
useful).
I don't have to explicitely write a slot for this (and maybe even add
Q_OBJECT stuff and whatnot). If this code is inside a template, I cannot
use Qt signals at all, as shown above.
However, there is one situation where I prefer Qt signals, and that is
when synchronizing the thread where the Qt GUI runs with the worker
thread. Since Qt Signals are threadsafe, they do syncing automatically,
something boost.signals won't do.
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest
