On Sun, Jan 18, 2009 at 8:56 AM, Lasse Kärkkäinen <[email protected]> wrote: > I hope that Wt stays away from Qt because the library does not follow > good C++ practices. It enforces OOP everywhere, it requires a special > precompiler that breaks when you try to use templates. It doesn't use > namespaces, exceptions or templates, all of which are very central parts > of modern C++.
Bullshit. Enforcing OOP everywhere is a good C++ practice. OOP is the central point of C++, in case you've forgotten. Special "precompiler"? It's actually a preprocessor but even then, what's the problem with that? We already use one preprocessor( cpp, the C++ Preprocessor), so using two is not a problem for me. The only reasonable argument I have ever heard against "moc" is errors are difficult to debug (for instance when you forget to type Q_OBJECT and 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. Namespaces? Ever tried to build Qt with "configure -qtnamespace <namespace>" ? Exceptions? Qt does not use exceptions internally but you can use them in your application. We do. Did I say we have commercial Qt licenses, BTW? No support for templates? Are you joking? QList, QVector, etc are all template-based classes! > Boost is basically the opposite, building on top of functors, templates > and iterators where applicable. It does signal errors by throwing, as > good C++ code should, and everything is based on the RAII idiom, so that > you rarely see or have to use the new keyword anywhere, and you never > have to use delete. 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. > Should a better (but still bloated) support library be required, I > recommend glibmm. It has charset conversions, UTF-8 strings (with full > std::string and iostream compatibility) and very feature-rich XML (via > libxml++), all in good C++ style. It also has signals, but it isn't very > clear whether Boost.Signals or SigC++ is better. Both are better than > Qt's approach, though. 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. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ------------------------------------------------------------------------------ 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
