Le mardi 25 novembre 2008, Lalo Martins a écrit : > quoth Lauwenmark Akkendrittae as of Mon, 24 Nov 2008 20:02:49 +0100: > > Le lundi 24 novembre 2008, Lalo Martins a écrit : > > I see two good reasons for Nicolas favouring Qt over Boost: > > > > - He's more familiar with Qt, and having to learn another toolkit, > > especially something as complex as Boost, would be somewhat of a waste > > of time; > > Agreed. > > > - Although you mentioned several things that integrate nicely with > > Boost, providing Internationalization or a crossplatform building > > system, the whole point is that all of this is provided inside the Qt > > tool suite, and requires no external/3rd party dependency. This is a > > significant advantage to me. > > That's true for ICU, but not Jam; Jam *is* part of the Boost tool suite. > True only if you were speaking of the Boost version of Jam. I had the Perforce version in mind, which is an independent tool.
> > My own, personal tastes lean towards Qt more than Boost, mostly for the > > way Qt extended the C++ language to make some fundamental mechanisms > > more accessible. It provides a level of simplicity more in touch with > > the capabilities of my old braincells :). > > Hmm... the same could be said for Boost, > Nope. I have worked (and still does) with Boost; it mostly builts upon existing language structures. From my personal experience (note the "personal" both here and my initial comment), Boost was not as easy to use as Qt. So yes, Boost provides an extensive, consistent library; yes, it allows using C++ in a very powerful way; no, it doesn't fundamentally make any of the language mechanisms simpler. > and the improvements in Boost > are more likely to be in future versions of the C++ standard, since > there's a huge overlap in membership between the C++ committee and the > Boost project. That's one of the main reasons I favour Boost. > I don't see how what a future C++ standard may someday include would be of any relevance here. Being Qt or Boost, the code would still be C++ anyway. > Also, here's something I forgot before: would use Qt imply using > Trolltech's bastard C++ dialect, and MOC? > There we hit your real issue, don't we? Short answer: yes, you have to use MOC, and yes, it implies using its language extensions. I see no point in commenting the "bastard" qualifier here - I care about the efficiency of a dialect, not about its possibly illegitimate origins. > Or is that already dead and outdated? > This simple question tends to demonstrate your quite superficial knowledge of Qt, else you wouldn't even have asked. Maybe you should evaluate both libraries before actually placing a judgement of their respective qualities/flaws ? > If we'll have to code in a C++ dialect and require a toolset > that not many people will already have installed, then I'm strongly > opposed to Qt. > The dialect point could indeed have been an issue - nobody wants to learn a variety of C++ just for a single project. But the changes are actually extremely limited - the most important being the addition of signal/slot mechanisms. It doesn't invalidate any of the existing C++ language definition. So far, I haven't seen many C++ coders complaining that the "Qt Dialect" was difficult to grasp. Regarding the toolset, I don't see where the problem is, since the required tools are shipped with the Qt SDK. Since the Boost libraries themselves are not installed by default on most platforms, I don't really get where the difference is. -- Lauwenmark. ------------ "Drive defensively: buy a tank."
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
