> Enforcing OOP everywhere is a good C++ practice. OOP is the central
> point of C++, in case you've forgotten.
I need to remind you that C++ is a multiparadigm language. This means
that you can do procedural, ADT/OOP or functional development with it.
You can even use template metaprogramming or define a meta language with
operator overloading (Boost.Spirit is a wonderful example of this).
Enforcing the use of OOP is just plain wrong. In Qt you cannot use any
suitable functor as a slot as the system forces you to use classes with
Q_OBJECT in them only. Another side-effect of this is that it is
intrusive - the class in question needs to be "polluted" by Qt and MOC.
The standard C++ approach is overloading operator() with suitable
arguments. A non-intrusive solution, as a class written this way works
with any standard C++ code, including SigC++ and Boost.Signals, and
doesn't need any #includes or special tools from the signal framework.
> Special "precompiler"? It's actually a preprocessor but even then,
> what's the problem with that? We already use one preprocessor( cpp,
It doesn't necessarily work with external tools (e.g. IDEs) and it
requires special handling in the build system.
> the C++ compiler complains about the metaobject, etc) . But given the
> extremely confusing output any C++ compiler spits when it finds a
> problem with templates, even more when using Boost, I'd rather face
> "moc" than Boost templates.
At least you get a line number within your own code when doing it with
templates.
SigC++ feature list mentions that they paid special attention to this:
"Typesafety violations report line number correctly with template names
(no tracing template failures into headers)"
> Namespaces? Ever tried to build Qt with "configure -qtnamespace <namespace>" ?
Wait a sec.. I need to recompile the library that I use to get namespace
support? Will that also remove the Q prefixes? What about other code
that uses the library, but doesn't assume it being compiled with that
option? Seriously, this is not a solution.
> Exceptions? Qt does not use exceptions internally but you can use them
> in your application. We do.
Obviously you can use them internally, as Qt has no way of knowing you
do, but correct me if I am wrong: you cannot pass them thru Qt's signals.
Not using exceptions to signal errors pretty much collapses the entire
language, or a large part of it at least.
No exceptions
=> there is no way to signal errors from constructors
=> more objects get constructed even though an error has already
occurred, before the error can be checked (e.g. via isError())
=> cannot do construction in constructors
=> have to use two-phase construction instead (init methods)
=> RAII idiom (a *very* central part of good C++) breaks
=> half-initialized objects (init called yet? did it fail?)
=> have add logic to each member function to verify object state first
In the end you have a total mess that is far different from what I know
as C++.
For example, construction of a simple class like this will become a very
complex operation:
class Widget {
Foo m_foo;
Bar m_bar;
public:
Widget(int a, int b): m_foo(a), m_bar(b) {
Baz baz(a + b);
std::cout << "Baz: " << baz << std::endl;
}
// (member functions)
};
In the example above exceptions and RAII take care of proper resource
management, no matter which part of the operation fails. E.g. if m_bar's
construction fails, m_foo's destructor will get called before Widget's
constructor exits. Methods do not need to test if initialization is
complete because Widget will not exist if any part of the process failed.
> Did I say we have commercial Qt licenses, BTW?
I don't see what your licenses have to do with this, unless you are
trying to say that you are biased in order to protect your investment.
> No support for templates? Are you joking? QList, QVector, etc are all
> template-based classes!
Oh, yes. Another reason not to use Qt. Major NIH of standard library
features. I would also like to point out that templates are not just
generics, even though many people seem to think so.
I was referring to the signal system, though. It could provide
compile-time type-safety with standard C++ only, but instead they claim
that templates are not supported well enough and instead offer their own
code generator as a better option. Might have been so 10 years ago, but
this is just not true, today.
> Boost signals and slots are a blatant copy of Qt signals and slots.
> Not having to use "delete" is also a feature in Qt. In fact, those
> features have been in Qt from before Boost was born.
The signal concept predates Qt by a decade at least. Qt made it more
flexible, but SigC++ and Boost.Signals together take a completely
different implementation approach, which is also far more sensible now
that you can actually use templates to your heart's extent on all
platforms without issues.
However, even if others did take ideas from Qt, wouldn't you say it
would be stupid not to? Remember that C++ and Java both "blatantly
copied" C in an attempt to create better languages.
> Are you joking? glibmm is only a small subset of QtCore. We are
> talking about expanding Wt features "for free", not about changing
> from Boost to anything else just because we feel like it.
Glibmm is not an alternative to Boost, it only has some overlap (threads
and signals, most importantly). There are a large number of helpful
tools in Boost and in the standard library, not needlessly reimplemented
by glibmm.
I suggest that Wt keeps using Boost and seeks to use more of its
facilities than are currently being used, even if it also starts using
Glibmm and LibXML++.
------------------------------------------------------------------------------
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
