Discussion :

[superjaja]

Je crois que le sujet du débat change là...

[yan]

C'est le genre d'annonce qui sert à rien vu qu'il n'y a pas d'arguments précis.

j'avoue que c'est un peu trollesque cette partie
Toute façon un débat gtk vs Qt n'amènerais pas à grand chose. L'un est en C l'autre en C++.
A la limite gtkmm vs Qt, mais bon. Ces deux framework propose quasiment les même choses.

[Firwen]

j'avoue que c'est un peu trollesque cette partie
Toute façon un débat gtk vs Qt n'amènerais pas à grand chose. L'un est en C l'autre en C++.
A la limite gtkmm vs Qt, mais bon. Ces deux framework propose quasiment les même choses.

Surtout que les deux frameworks deviennent de plus en plus complémentaires.

Depuis le "phénomène Ubuntu", le nombre d'applications 100% Linux codé en Gtk+ augmentent : il y a des raisons à ça.... meilleur intégration au bureau GNOME, temps de démarrage raccourci, etc...

Parallèllement Qt devient un framework hors-pair pour faire du multi-plateforme en code natif : Linux, Windows, MAC OS X, S60, QNX , Linux embarqué, Windows CE, BSD......

longue vie à Qt, Longue vie à Gtk+

[Altess]

il est clair que Qt est plutôt efficace. il propose des methodes utiles, et facilement exploitable. De plus, sa doc est plus que correcte. Ce sont ces petites choses qui rendent Qt plus clair, et plus lisible.

Coté performance, je n'ai jamais vraiment testé à vrai dire. Mais bon, comme souvent, ce benchmark ne veut pas dire grand chose. Tout dépend de ce que l'on souhaite codé.

[Nogane]

Je n'utilise pas Qt mais je vais m'y mettre tôt ou tard. De ce que j'ai pu en voir, Qt et simple et puissant.

En revanche je regrette ce genre de comparaison entre Qt et la STL.
D'une par car Qt n'as pas a vouloir remplacer la STL. Parque ce n'est pas ce qu'on attend de lui, et aussi parque ce serai ce rendre totalement dépendent de Qt.

D'autre par, la fonction split n'existe pas dans la STL. Ce test ne peut donc pas prouver que la STL est moins clair ou plus lente, il prouve seulement que la STL ne contient pas autant d'outils que Qt. Ça c'est évident.

Une comparaison entre Qt et boost.tokenizer aurait été, a mon sens, bien plus intéressante.

Par example:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
#include <QString>
#include <QStringList> 
 
QString str("abc:def");
QStringList tokens = str.split(':');

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
#include <string>
#include <vector>
#include <boost/tokenizer.hpp>
 
using namespace std;
using namespace boost;
 
string str("abc:def");
tokenizer<char_separator<char> > tok(
  str, 
  char_separator<char>(":") );
vector<string> tokens(tok.begin(), tok.end());

Qu'est-ce qu'on peut y voir?
La version boost est plus complexe, pour plusieurs raison:
- boost est dans un namespace et j'ai choisit de faire des using namespace.
- On doit définir le séparateur, ce qui n'est pas a faire dans Qt vue qui n'y as pas 36 types de séparateurs.
- boost utilise une syntaxe STL-like ce qui fait qu'on peut utiliser tokenizer avec n'importe quel conteneur STL-like, c'est à dire même avec Qt(jusqu'as la version 3 car après ils ont abandonné les iterateurs STL-like). Le conteneur n'est pas imposé comme avec Qt.

Voila donc mon avis personnel sur cette exemple précis (comparaison Qt/STL/boost au niveau du split):
Qt est certainement plus clair et plus concis, ce qui est très bien dans certain cas.
La STL ne gère pas le split directement. La STL est assez ancienne certes, et c'est pourquoi il y a boost.
Boost gère très bien le split, mais de manière très modulable/paramétrable, c'est au pris de la clarté, comme toujours, mais c'est très bien aussi, dans d'autre cas.

[Niak74]

Voté "Qt améliore la productivité et les performances".

Je bossais au début avec Java, je suis ensuite passé dans le monde du C++ avec Eclipse et WxWidget.

Depuis que je me suis mis à Qt, j'ai tous les avantages de Java pour ce qui est de la philosophie OO, et tous des avantages du C/C++ pour ce qui est des performances (Java n'est pas réputé pour sa rapidité). En plus de ça, je suis multiplateforme et j'ai des outils tout prêt pour la cross compilation (je développe pour appareil portables), que demander de plus?

Je commence à maitriser le Framework, et je dois avouer qu'on gagne énormément en temps de développement en utilisant les outils proposés par Qt. Ceux-ci ayant été optimisé, on y gagne en performances et en temps de debug (très spécialement en tout ce qui concerne malloc/free | new/delete).

Les principaux + :
- C/C++ = rapidité
- Framework riche (beaucoup de classes bien pensées et toute faites)
- GUI élégant
- Documentation très claire
- Outils puissants
- Un IDE spécialement conçu pour Qt (QtCreator)

[dourouc05]

Je bossais au début avec Java, je suis ensuite passé dans le monde du C++ avec Eclipse et WxWidget.

Depuis que je me suis mis à Qt, j'ai tous les avantages de Java pour ce qui est de la philosophie OO, et tous des avantages du C/C++ pour ce qui est des performances.

Qu'est-ce qui t'a fait changer de framework ? Qt correspondait-il mieux à ton passé de java-iste ?

Utiliser le C ou le C++ n'est pas forcément gage de rapidité. Si l'algorithme d'un code est mal fait, qu'il soit en Java ou en C, il sera lent. Un programme Java exploitant un bon algorithme sera plus rapide qu'un programme C++ avec un algorithme pondu en 5 secondes.

[Niak74]

Ma boite souhaite développer des outils portables, à base de C/C++. Je me suis tourné d'abord vers WxWidget pour ce qui est du GUI puis j'ai découvert Qt. Mieux présenté, mieux documenté, en perpétuel développement, et proposant les outils qu'il me fallait pour aller plus vite (Traduction, Cross compilation, et émulateur virtuel de device (QVFb) notamment). C'est principalement les démos, vidéos, et nombreux tutos qui m'ont convaincu de faire le saut.

J'ai ensuite développé mon premier projet, il m'a fallut environ 3 fois moins de temps qu'avec WxWidgets (Installation, apprentissage du framework, développement, debug).

Pour ce qui est des performances, les anciens de ma boite s'accordent à penser que C/C++ est plus performant que Java, je leur fait confiance sur ce point. Question algorithme bien écrit, il faudrait interroger un expert Java et Qt pour avoir le comparatif, mes connaissances en Java n'étant pas assez poussées pour établir un tel test.

[dourouc05]

Pour ce qui est des performances, les anciens de ma boite s'accordent à penser que C/C++ est plus performant que Java, je leur fait confiance sur ce point. Question algorithme bien écrit, il faudrait interroger un expert Java et Qt pour avoir le comparatif, mes connaissances en Java n'étant pas assez poussées pour établir un tel test.

C++ est plus rapide que Java, parce qu'il est directement exécuté sur le processeur, les instructions ne doivent pas d'abord être converties pour le processeur (ce que font, en très gros, les machines virtuelles : JVM, .NET...). Voici ce qu'il fait qu'il est plus rapide, en général.

Maintenant, avant de se lancer dans l'optimisation du code, il faut se lancer dans l'optimisation de l'algorithme. Un bon algorithme, bien optimalisé, sera bien plus rapide qu'un algorithme bâclé. C'est en cela qu'un programme en Java peut être bien plus rapide qu'un programme en C++.

[Aurelien.Regat-Barrel]

Un aspect très important des performances / optimisation qui est souvent négligé concerne les structures de données / l'organisation mémoire. En particulier la manière d'allouer ses objets a un grand impact sur les performances. De ce côté là je trouve Qt assez pauvre (pas de pool d'allocation par exemple), même s'ils se distinguent avec leur utilisation du Copy On Write (ce qui limite les méfaits d'un code C++ maladroit un peu comme le garbage collector de Java optimise l'organisation mémoire des objets).