> > > >> I know it's a huge change but here are my 2 cents: > >> - Boost is slow
Would you be able to point to somewhere that provides some comparisons? I was under the impression that since templates are basically a compile-time thing, the compiler can optimize a bunch of stuff at the time of compile, and maintain compile-time type safety. Qt does a bunch of run-time type-safetying, which, by definition, increases runtime. This is the perennial problem of run-time optimization or program space optimization. > > That is true but I think it is mostly Boost.Signals that contributes > > in this way to the size of Wt (since for every combination of types, > > new code is instantiated). But I do not think that warrants going > back > > to a moc approach, since this is the single most criticized design > > feature of Qt, which was very defendible at the time but no longer so > > given current state of C++ (and compilers). > > To moc or not to moc is not really an issue, IMHO. I would put my two cents and say that I dislike moc'ing. I don't use those parts of Qt that require moc'ing... Which does leave out a bunch of fancy stuff. When boost doesn't have something, I've used some stuff from QT. And if I can't use stuff from there, I'll move onto POCO, et. al. > > >> - Qt provides lots of features Boost does not even dream of having I suppose QT is the open source world's answer to Microsoft's CLI (aka .Net). > > > > Now that is true -- Qt is without doubt the single library that would > > be the most valuable dependency for having in Wt. Although it cannot > > replace Boost.Signals in my opinion, it could possibly replace > > anything else that we use of boost, and provide many new features: > > Why can't Qt signals and slots replace Boost.Signals? IMHO Qt signals > are better than Boost signals: they can be queued, introspected, can > ignore parameters, etc (see > http://web.archive.org/web/20070703100120/http://scottcollins.net/artic > les/a-deeper-look-at-signals-and-slots.html > ) Even after reading through that, I am still of the belief that compile time type checking and optimization has a valid position in program composition. And it high utilization web sites, at the cost of extra program size through template instantiation, good run-time does have its merits. > > > - raster image paint devices for WPainter, > > - QSvgRenderer for rendering an SVG file on a WPaintDevice (and > > implicitly converting SVG to VML or canvas) > > - more unicode transcoding support besides UTF8, > > - database access layer, > > - application-level networking protocols (email, ...) > > - scripting > > > > It remains the question whether Wt should make the decision to adopt > > Qt, or whether we should wrap selected Qt features as an add-on > > library that integrates well with Wt (e.g. for some of the features > > mentioned) or whether it presents an opportunity for Wt application > > developers to leverage Qt features where needed. Adopting it with wrapping, and if at all possible, without moc'ing, would be of value to me. > > > And, allthough a LGPL license allows closed source applications, it > > does prohibit static linking, which still results in a much larger > > flash footprint in embedded systems (since static linking allows the > > linker to dismiss unused symbols), and this should be kept in mind as > > well. > > No need for dynamic linking. It is generally agreed the LGPL allows > static linking as long as you provide the compiled source (i. e. > object files) you would need if you were to re-link your application > to a newer version of the LGPL library (Qt, in this case). Whatever the outcome, static linking is preferred for me. -- Scanned for viruses and dangerous content at http://www.oneunified.net and is believed to be clean. ------------------------------------------------------------------------------ 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
