Discussion :

[KeLx86]

Bonjour,
J'ai lu quelques sujets concernant les librairies graphiques ( QT,wxWidgets...), j'ai besoin de faire une GUI ou le client n'aurai vraiment que le .exe et pas 2-3 lugins sous forme de DLL en plus, est ce que c'est possible et quel lib graphique me conviendrai dans mon cas ?

merci !

[Melem]

Dans ce cas tu dois utiliser directement les APIs de l'OS sur lequel sont destinées à fonctionner tes applications. Vu que tu parles de .exe, t'es sans doute sous Windows et donc les APIs en question ici sont ... les APIs de Windows. Voici un tutoriel pour démarrer : Bases de la programmation sous Windows.

[Aurelien.Regat-Barrel]

Qt, wxWidgets, et pour ainsi dire la plupart des libs en general, peuvent etre liees de maniere statique, et alors l'exe final ne depend d'aucune dll. Donc ce n'est pas un veritable critere.
Je vais faire court : si tu peux te payer Qt, y'a pas a hesiter.

[KeLx86]

Dans ce cas tu dois utiliser directement les APIs de l'OS sur lequel sont destinées à fonctionner tes applications. Vu que tu parles de .exe, t'es sans doute sous Windows et donc les APIs en question ici sont ... les APIs de Windows. Voici un tutoriel pour démarrer : Bases de la programmation sous Windows.

L'API Windows, c'est pas le plus esthetique mais je risque de m'y résoudre, merci !

Qt, wxWidgets, et pour ainsi dire la plupart des libs en general, peuvent etre liees de maniere statique

Hmm d'accord, en gros si j'inclue la lib dans mon project, plus besoin de DLL mais mon project va prendre beaucoup de kilos d'un coup (voir MO)
Sinon QT, c'est pas cheros ? 2k € non ?

[Aurelien.Regat-Barrel]

Tu utilises la lib de la meme maniere. C'est juste a l'edition des liens que ca se passe. Tu link avec la version statique, et voila.
L'exe final est plus gros, mais en fin de compte, moins qu'avec les dlls. Car au lieu d'avoir plusieurs grosses dlls, l'exe ne va contenir que les portions de code necessaires, l'editeur des liens etant capable de se passer du code inutile. De plus, il pourra aussi mieux optimiser.

Le tarif de Qt depend de ce que tu prends et du nombre de plateforme(s) visee(s). Si tu mets en balance le cout d'une license avec celui d'un developpeur passant son temps a decouvrir l'API Win32 et a se coder sa petite lib a la Qt, tout est relatif Faut voir aussi que tu obtiens une qualite de documentation / outils / support.

Enfin bref, tout depend de tes besoins. Si c'est pour une petite appli codee en 2 semaines, c'est pas rentable et wxWidget fera l'affaire. Maintenant si c'est un truc plus costaud avec plusieurs mois/homme de developpement, ca peut etre tres vite amorti.

[Melem]

L'API Windows, c'est pas le plus esthetique mais je risque de m'y résoudre, merci !

Qu'entends-tu par "esthétique" ?

en gros si j'inclus la lib dans mon projet, plus besoin de DLL mais mon projet va prendre beaucoup de kilos

Dans ce contexte, le fait d'utiliser les DLLs n'est réellement avantageux que si tu projettes de créer un bon nombre de logiciels qui en font usage, sinon vaut mieux opter pour la liaison statique lorsque cela est possible.

[r0d]

Sinon, si la portabilité n'est pas une contrainte, une solution que j'aime bien consiste à implémenter l'IHM en C# avec les winform, et les classes métier en C++ via un wrapper C++/CLI. Ca parait compliqué dit comme ça, mais cette méthode a plusieurs avantages:
-> développer une IHM avec les winform en C# est ce que j'ai vu de plus simple et plus complet
-> une fois mis en place le projet (3 parties: ihm en c#, wrapper c++/cli, classes metier), ça va tout seul
-> on profite ainsi de la grande variété du framework .Net en terme d'ihm, et de l'efficacité du c++ pour les classes métier

désavantages:
-> non (ou très difficilement) portable
-> sans une version payante de ms visual studio (7 ou 8), c'est plus compliqué
-> les ihm basées sur le framework .Net peuvent être assez lentes si on ne fais pas attention

[ac_wingless]

La solution proposée par r0d est excellente, moyennant une grande attention à des problèmes de performance curieux dans Winform.
Après évaluation, nous utilisons aussi CodeGear C++ Builder 2007, qui est nettement meilleur que C++/Winforms, un peu moins bien que C#/Winforms (essentiellement à cause de l'intellisense trop lent / troué, mais sinon pratiquement identique), et a l'avantage d'être en C++ natif sur l'ensemble du projet, sans les hoquets bizarres et inattendus des IHM Winforms.
Par contre, C++ Builder ne dispose pas de tous les atouts de VS 2008 (par exemple pas de support DirectX, pas moyen de compiler Boost 1.35.0, etc.), donc il faut parfois mixer les deux codes, ce qui se fait assez facilement mais reste pénible (toujours pas d'ABI pour C++, et petites subtilités de portage entre les deux compilateurs).

[yan]

-> développer une IHM avec les winform en C# est ce que j'ai vu de plus simple et plus complet

tu es sur?? je te rappel ta première IHM avec...
Qt est un très bonne alternative. Sachant qu'elle fournie beaucoup plus de chose qu'une IHM, comme les thread, xml, webkit, gestion 2D, ...
et ce de manière portable et trés simple.
On ne sait jamais comment une appli peut évoluer.

[r0d]

tu es sur?? je te rappel ta première IHM avec...

Nan, c'était pas avec l'IHM que je galérais, mais avec les classes métiers justement (j'ai du mal avec la philosophie du C# )

Qt me parait effectivement une bonne solution, mais comme je ne connais pas du tout, je me garderai bien de tout commentaire

edit: en fait si j'avais un peu galéré aussi avec l'IHM, justement à cause des problèmes de performances... :/ Mais je me souviens surtout comment j'avais galéré avec Qt quant j'avais essayé de m'y mettre, il y a 2 ans environs :^(