tanguy_k a écrit 766 commentaires

En C++ c'est chaud pour la programmation aspect, la reflexion...

> La gestion des fichiers, la base de données, ca c'est dans la couche
> de persistance, pas dans la couche métier malheureux

J'ai un object triangle, si je veux le serializer, j'appelle la methode serialize() de l'objet qui me retourne une string (XML), ensuite suivant mon data layer la string est envoyee vers un fichier ou autre (SOAP, database...). Donc oui tout ca est dans ma couche metier.

Tu ferais comment toi ?

> apprendre un nouveau langage

Si tu connais C++ ou Java je pense que tu n'auras aucun probleme a assimiler C# rapidement. Je lis (et comprends) tous les jours du code source ecrit en C# (que je n'ai pas ecrit donc) alors que j'en ai jamais fait. C'est franchement pas complique, au contraire. Quelques fois il faut se lancer, c'est comme cela que l'on progresse et que l'on apprend de nouvelles choses.

> couche métier ?

En gros c'est l'ensemble des composants moins les composants graphiques (e.g les algorithmes, la gestion des fichiers, la base de donnees ect...)

> Le projet est à but éducatif mais pas seulement : il doit aussi pouvoir
> être utilisé par des professionels en quête de ses services (à terme)

Et ca pause un probleme si les utilisateurs doivent installer une JVM ou le framework .NET ? Si l'interface n'a pas le look and feel du natif (Java Swing) ?

Personnellement je ne me poserai pas la question comme ca.
Je me poserai plus des questions sur le projet lui-meme pour trouver l'outil adapte a la realisation de celui-ci

Le projet demande t'il une interface graphique complexe ?
Le projet demande t'il une couche metier complexe ?
Le projet doit-il etre multiplatformes (les contraintes du projet) ?
Le projet demande t'il beaucoup d'acces aux 'perifs' de la machine (audio, port USB ect...)
Le projet est-il principalement a but educatif ?
ect...

C++ est apparu en 1983, Java dans les annees 90 et depuis peu C#
Il est evident que l'on developpe plus vite avec un language comme C# que C++. D'apres ma propre experience, on developpe au moins 2 fois plus vite en Java qu'en C++ pour un meilleur resultat du point de vue qualitatif.

Qt est une tres tres bonne librairie graphique et on peut esperer developper une interface graphique bien plus vite avec qu'en Swing (Java) (en C# je sais pas) grace a Qt Designer notamment pour un meilleur resultat visuel. Pour OpenGL il n'y a aucun soucis pour l'integration avec Qt. Qt Designer est tres performant, je l'utilise systematiquement pour generer des fichiers .ui (XML) et charger ceux-ci au lancement de l'application (comme avec Glade pour GTK+) sans meme demander a Qt Designer de generer du C++. Donc dire que le mieux est de tout faire a la main est totalement faux: c'est une perte de temps evidente.

Si tu n'as pas de contrainte sur les outils utilises pour le projet, ni sur le projet lui-meme en dehors des fonctionnalitees, moi je le developperai en C# tout simplement pour apprendre un language qui est cense etre l'un des plus modernes actuellement. Je laisserai soigneusement le debat du language entre les integristes.

> appliquer un modèle appris en cours, le modèle PAC

As-tu de la documentation sur PAC et les modeles du genre ?
Ca m'interesse enormement !
Merci

> Pourquoi tous ces developpement proprio ou semi proprio utilisent
> encore OSS ?

Parceque c'est plus simple de developper avec OSS que Alsa (enfin c'est ce que j'ai entendu dire). De plus ca fonctionne sur les autres UNIX ce qui n'est pas le cas d'Alsa.

Et ta remarque "developpement proprio ou semi proprio" ne veut rien dire puisque TOUT le code source de Wengo est disponible via svn et celui-ci est integralement sous licence GNU GPL.

Si mais pas toujours tres bien: le soft utilise OSS et non Alsa
http://www.openwengo.com/(...) ->get it!
http://dev.openwengo.com/trac/openwengo/trac.cgi/wiki/WengoPhone(...)

Oui cf http://dev.openwengo.com/trac/openwengo/trac.cgi/wiki/WengoPhoneCSh(...) et http://dev.openwengo.com/trac/openwengo/trac.cgi/wiki/WengoPhoneNG(...)

Si je pose la question c'est justement parceque bksys ne semble pas etre ce que je cherche. cf qui permet de remplacer les GNU autotools (autoconf, libtool, ...)"

J'utilise scons, ca marche pas trop mal mais par rapport a qmake et les .pro c'est pas aussi simple (c'est du plus bas niveau). Je prevois de creer un ensemble de fonctions par dessus scons pour le rendre aussi simple a utiliser que qmake/.pro. Si quelqu'un a deja une 1er experience avec scons ca m'interesse d'avoir son avis sur le sujet.

> Un peu déçu par les nombreux petits bugs de Qt 4.0.0

Je suis sous Windows et il y en avait pas mal et il en reste encore plein.
Qt 3.3.3 avait beaucoup moins de bugs.

> il est beaucoup plus difficile de "binder" ce langage dans d'autres langages.

Faire un binding par dessus C++ a la mano oui c'est chaud.
En revanche automatiser la creation d'un binding par dessus C++ c'est apparemment "facile".

Le C++ est plus "verbeux" que le C: on a plus d'informations:
classes, methodes privees/public, heritage... Toutes ces informations peuvent etre exploitees (ou non) par un parseur (par exemple doxygen). Plus celui-ci a d'informations mieux c'est car il pourra generer un binding plus efficacement contrairement a C ou l'on a juste des structures et des fonctions.

Richard Dale qui s'occupe des bindings pour KDE l'avait explique dans une interview. Le probleme des bindings KDE c'est qu'il n'y a pratiquement personne pour travailler dessus. De plus beaucoup de devs sont satisfaits avec C++/Qt alors que pour C/GTK+ il y a une vrai demande.

> quand la JVM passe son temps à m'exploser à la figure
> ou à bouffer 350 Mo de RAM

Un language et l'implementation d'un language sont 2 choses distinctes. C'est pas parcequ'il existe une implementation pourrie qu'il faut jeter l'eau du bain avec le bebe. Il suffit de voir l'integration de Java sous Mac OS X pour s'en convaincre.

> sur le "desktop" ? pratiquement n'importe quoi d'autre

Java pour le desktop en terme de simplicite de developpement, de rapidite, de maintenance, de portabilite, de lisibilite du code est tres tres largement superieur a C/GTK et C++/Qt.
Le jour ou GCJ (ou harmony) sera devenu mature, Java aura de gros avantages par rapport aux outils communement utilises.
Ceci dit je ne fais plus de Java mais du C++ a cause de cette histoire de JVM...

> Si il avait écrit son programme en C il n'aurait pas eu de problèmes
> de VM propriétaires.

Java n'est pas moins libre que le C. Si personne n'avait developpe un compilo C libre on aurait ete dans le meme cas que Java actuellement. Un language et l'implementation d'un language sont 2 choses distinctes.

Rien n'empeche l'implementation d'une JVM libre, d'ailleurs ca existe deja.

> je me suis amusé un instant à vérifier ma présence dans
> fr.comp.lang.java en 1999

C'est si complique de donner des arguments credibles et convaincants pour quelqu'un qui programme en Java depuis 1999 ?
Tu proposes quoi comme alternative a Java ?

> Ce qui fait le succès de Skype, c'est surtout le principe de p2p
> pour passer tous les firewalls

Le P2P et le passage des firewalls ca n'a rien n'a voir. Wengo ne fonctionne pas en P2P et on passe la plupart des NAT. Pour la prochaine version il y a un tunnel HTTP qui est meme configurable pour utiliser les proxy locaux genre NTLM. Il y a aussi le protocole IAX qui contrairement a SIP a ete prevu des le depart pour contourner les firewalls et autres NAT.

Pas super cool de mettre ca sur kde-apps.org sans avertir les developpeurs et encore moins leur en parler
Surtout que la version Linux n'a pas ete finalisee, il manque pas mal de choses contrairement a la version Windows. D'ailleurs la version Linux ne compile pas actuellement.
Il faut mieux encore attendre pour la version Linux sous peine d'etre decu.

> > Ca utilise le preprocesseur, c'est pas du C++
> Tu sais, le C++, c'est beaucoup de choses.

Je ne suis pas contre l'utilisation du preprocesseur, mais faut avouer qu'ecrire ca:

class Toto : public QObject {
Q_OBJECT
public slots:
void activate();

signals:
void activated();
};
Malheureusement aucun outil du type Rational Rose, Together ect... ne le supporte. Ce n'est pas l'implementation qui est changee en utilisant le preprocesseur mais carrement la declaration d'une classe !
Sans compter qu'il y a aussi des problemes tordus du style: il faut heriter de QObject en premier sinon ca marche pas.

Trolltech explique pourquoi ils utilisent le preprocesseur (http://doc.trolltech.com/3.3/templates.html(...) ), pas de probleme je ne suis pas contre mais de grace c'est franchement crado de modifier la declaration d'une classe surtout que l'on peut faire autrement cf libsigc++/boost/sigslot/SlotSig. Pour le moment beaucoup de developpeurs n'utilisent pas vraiment UML et les IDE qui vont avec mais c'est clairement l'avenir.

> les signaux/slot facon Qt

Ba justement moi c'est la facon Qt de gerer les slots/signaux que je trouve pourrie. Ca utilise le preprocesseur, c'est pas du C++. Impossible d'utiliser des outils avances de modeling parceque l'outil reconnait le C++ pas un truc bidouille. Quand on programme en Qt on se retrouve avec des outils genre vim, emacs, notepad...

On est au 21e siecle, moi je veux utiliser UML, OCL, round-trip engineering... parceque je programme beaucoup beaucoup mieux et plus vite avec.

Sans compter que pour utiliser les classes XML, reseau, string, timer ect... on doit se tapper TOUTE la lib Qt. Oui je sais dans Qt4 ca sera separe (bien separe??) mais en attendant ca fait 10 ans que tout est lie et c'est franchement crado.

Mon avis: Qt est la moins pire des librairies graphiques C++ donc je l'utilise et au final c'est pas mal du tout.

Gnomemeeting est programme en C++
cf http://cvs.gnome.org/viewcvs/gnomemeeting/src/(...)

Il y a une difference entre open source et Open Source.
open source signifie en anglais que le code source est ouvert, disponible.

> Ce n'est pas parce que le gain entre java et c# ne sera que de 5% en
> terme de temps de développement que l'un ne prendra pas le pied
> sur l'autre.

Cela depend de ce qu'on inclue dans ce gain. Je pense qu'il faut tout prendre en compte: les libs, le compilo ou VM, mais aussi les outils disponibles comme editeur, debuggueur, generateur d'interface ect...

> parce que tout simplement ça marche mieux...

Ca je n'y crois pas, je ne change pas ma pigo 205 pour une 206 parceque celle-ci "marche mieux". Comme pour les voitures, changer de language de programmation a un cout. Pour une entreprise le cout peut etre enorme, j'ai bien des amis qui programment en COBOL en entreprise !

Donc je te pose la question, moi (entreprise ou particulier) quel est l'avantage d'abandonner Java ou C++ au profit de C# ? j'y gagne quoi ?
Pour l'instant il faut installer un truc qui fait jesaispascombiendeMo pour executer du C#.
Pour l'integration avec le C je peux le faire tres facilement en C++, Python, Objective C et en Java c'est aussi possible. Et puis ca se trouve j'ai tout simplement pas besoin de m'interfacer avec du code C. En Java par exemple, je n'ai personnellement jamais eu besoin de reutiliser du C, il y a deja pas mal de composants et de libs en Java (c'est meme plutot l'inverse, je trouve pleins de trucs en Java alors que je le voudrais en C++).

> Quid de C# dans l'histoire, il permet aussi beaucoup de choses.

C# est surement meilleur que Java, l'inverse serait etonnant puisqu'il a ete cree apres Java et donc ils ont pu voir ce qui fonctionnaient bien de ce qui ne fonctionnaient pas parfaitement.

En revanche il faut quantifier ce "meilleur". C++ par rapport au C apporte enormement de choses (notamment la POO) qui permettent de developper beaucoup plus vite et mieux.
Java par rapport au C++ apportent egalement enormement, rien que le garbage collector est en grand pas en avant. Dans le livre Thinking In Java, Eckel explique notamment que l'on developpe 50% plus vite en Java qu'en C++ sans compter tous les autres avantages (pour info Eckel fait ou faisait parti du commitee de standardisation du C++).

Maintenant avec C# est-on 5% plus efficace qu'en Java ou 50% ? Es ce que des innovations aussi importantes que le gc ou la POO a leurs epoques on ete introduites dans C# ?

Tout ca pour dire que si C# est seulement un peu mieux que Java, peu de gens vont changer leurs habitudes, leurs codes, leurs outils, leurs connaissances pour quelque chose qui au final n'apporte que peu d'ameliorations. La preuve: le C qui a 30 ans est encore beaucoup utilise alors que des languages bien meilleures existent depuis longtemps.

Je dis ca mais je n'ai jamais teste C# (juste lu des docs et des examples de code), mais je pense (peut etre a tord) que ces ameliorations sont mineures par rapport a Java ou a d'autres languages existants.

PS: pas la peine de retorquer qu'en C on peut faire de la POO, que Java n'a pas invente le gc, que Python et que Objective C... je le sais mais il faut faire court :)

> a) Qt c'est mignon mais ce n'est pas une lib standard du systeme sur Linux

On s'en fou on ne parle pas de ca, c'est un autre debat.

> b) Si tu savais utiliser CreateProcess

C'est le probleme justement, il faut un bac+10 et 5 ans d'experience avec cette API pour la maitriser et l'utiliser correctement, je suis desole mais je me suis arrete a bac+7.

> c) t'es libre d'utiliser d'autres APIs qui te permettent de faire des choses plus simples, plus simplement.

Ba voila on y vient enfin, tu nous expliques que Windows a les meme fonctionnalites que KDE depuis 10 ans sous entendu Windows c'est genial et KDE c'est des glands ils ne savent rien inventer mais juste copier.
Ba nan justement, les technologies Qt/KDE sont beaucoup plus simples et mieux foutus que celles de Windows tout simplement, d'ou leur interet.

> on dirait que t'as choisi de faire des cochonneries, libre a toi,
> mais c'est pas la meilleure maniere de programmer un soft.

Laisses moi seul juge de ce que je fais surtout si tu ne sais pas ce que je fais. Moi je ne juge pas ton travail et pour cause je ne sais pas ce que tu fais.

Le probleme de l'approche de wxWidgets c'est que suivant les plateformes, il y a probablement des bugs differents, des fonctionnalites manquantes, des trucs qui fonctionnent pas exactement pareil... Ca doit representer un boulot monstre de maintenir les differentes versions.

Je dis ca mais il est vrai que j'ai jamais teste, mais je vois mal comment ne pas rencontrer ce type de problemes et ca doit se sentir sur des gros projets.