[crossfire] C++/Qt server version

[Lauwenmark Akkendrittae]

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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20081126/2f552e32/attachment.pgp