Discussion :

[FloMo]

On est obligé de passer par une bibliothèque tierce en C++ pour la bonne raison que C++ dépend de l'OS tandis que Java se veut multiplateforme et proposer une couche d'abstraction.
Mais quand il s'agit de faire des graphismes double-tamponnage ( "double buffer" ) Java c'est pas génial et je préfère faire cela avec mes CreateCompatibleDC du gdi32

Java n'est pas fait pour les interfaces graphiques : le résultat est désastreux. Rien de tel qu'une véritable bibliothèque multi-plateformes.

[hegros]

On est obligé de passer par une bibliothèque tierce en C++ pour la bonne raison que C++ dépend de l'OS tandis que Java se veut multiplateforme et proposer une couche d'abstraction.

oui mais bon la couche présentation ce n'est plus un mystère pour personne c'est une grande partie des développements, le fait qu'en C++ de base il n'y a rien qui a été trouvé pour fournir un minimum cela montre une volonté de ne rien vouloir faire de ce côté ou tu vas me répondre qu'ils ne savent pas faire. Il nous reste donc qt qui corresponds à un style de programmation "moderne".

Mais quand il s'agit de faire des graphismes double-tamponnage ( "double buffer" ) Java c'est pas génial et je préfère faire cela avec mes CreateCompatibleDC du gdi32

[/quote]

windows c'est finalement ce qu'il y a de plus portable et plus performant n'est-ce pas...

Java n'est pas fait pour les interfaces graphiques : le résultat est désastreux. Rien de tel qu'une véritable bibliothèque multi-plateformes.

encore un qui a une vision binaire (un informaticien..encore...) adsl tv est loin d'être désastreux niveau graphique. dassault vient de baser la construction de sa nouvelle plateforme pour faire de la cao/dao sur une architecture java.

Donc arrêtez de dire n'importe quoi on peut faire aussi bien en assembleur, en windows api en c++ en java en cornshell en cobol aussi ce que vous voulez c'est juste que cela ne prendra pas le même temps (donc pas le même cout et les mêmes délais) et qu'on comprendra le code plus ou moins difficilement.

C'est quoi ta véritable bibliothèque multiplateforme que je me marre en mangeant mes cacahuettes

[FloMo]

encore un qui a une vision binaire (un informaticien..encore...) adsl tv est loin d'être désastreux niveau graphique. dassault vient de baser la construction de sa nouvelle plateforme pour faire de la cao/dao sur une architecture java.

En même temps, ADSL TV n'utilise pas les éléments GUI standard de Java, donc bon, forcément, après, c'est du travail de graphiste.

Quand je construit mon interface, de préférence, je n'ai pas envie de me retaper toutes les routines de dessins et suivre les guidelines des OS pour construire mes interfaces.

Au delà de l'aspect graphique des GUI, il est essentiel d'avoir une bonne ergonomie et donc une bonne intégration dans l'environnement ciblé. Le problème avec les interfaces Java est justement qu'elles sont reconnaissables car elles brisent l'ergonomie. (tout comme Gtk sous Windows par exemple) A contrario, les applications réalisées avec .Net, l'API Windows, Gtk sous Linux, Cocoa sous Mac et Qt sur chacune des plateformes s'intègrent parfaitement dans l'environnement.

Donc arrêtez de dire n'importe quoi on peut faire aussi bien en assembleur, en windows api en c++ en java en cornshell en cobol aussi ce que vous voulez c'est juste que cela ne prendra pas le même temps (donc pas le même cout et les mêmes délais) et qu'on comprendra le code plus ou moins difficilement.

C'est quoi ta véritable bibliothèque multiplateforme que je me marre en mangeant mes cacahuettes

Avec Qt, je te garantie que tu respecteras tes délais sans te prendre la tête avec la meilleure portabilité (bien meilleure qu'en Java). Dans un cadre commercial, tu vas payer la licence le prix fort mais sur la facture finale tu t'y retrouveras très largement.

Avec Java, le gros problème, c'est que dès que tu sors du cadre c'est une vraie prise de tête. Le problème est là : l'imprévu est le propre du développement. J'ai souvent vu des projets en Java exploser les délais, mais beaucoup plus rarement l'inverse.

.Net, Gtk et Qt n'ont pas ce genre de problème.

[hegros]

En même temps, ADSL TV n'utilise pas les éléments GUI standard de Java, donc bon, forcément, après, c'est du travail de graphiste.

si c'est un travail de graphiste alors en java ou c++ cela ne change rien.

Au delà de l'aspect graphique des GUI, il est essentiel d'avoir une bonne ergonomie et donc une bonne intégration dans l'environnement ciblé. Le problème avec les interfaces Java est justement qu'elles sont reconnaissables car elles brisent l'ergonomie. (tout comme Gtk sous Windows par exemple) A contrario, les applications réalisées avec .Net, l'API Windows, Gtk sous Linux, Cocoa sous Mac et Qt sur chacune des plateformes s'intègrent parfaitement dans l'environnement.

Tu peux trés bien mettre ta casquette de graphiste et faire des interfaces qui ressemblent à ce que tu veux

Avec Qt, je te garantie que tu respecteras tes délais sans te prendre la tête avec la meilleure portabilité (bien meilleure qu'en Java). Dans un cadre commercial, tu vas payer la licence le prix fort mais sur la facture finale tu t'y retrouveras très largement.

Qt cela vaut bien une cacahuette, cela ressemble à du vieux mfc qui a muté en gtk puis qui a muté qui a muté pour voir aujourd'hui quelque chose qui ressemble à du code java c'est à dire enfin exploitable, plaisant avec un degré de configuration/intégration qui ne paralyse pas.

Avec Java, le gros problème, c'est que dès que tu sors du cadre c'est une vraie prise de tête. Le problème est là : l'imprévu est le propre du développement. J'ai souvent vu des projets en Java exploser les délais, mais beaucoup plus rarement l'inverse.

En quoi le fait d'utiliser c++/qt ou java va permettre de gérer un imprévu ? ce sont des langages rien de plus qui traduise un travail d'une conception. Pis exploser les délais reléve d'une erreur de conduite de projet ou d'une mauvaise évaluation de scénarios pas du langage plus des programmeurs.

Je parlais de conception voilà dans le framework java il y a plus souvent de recours à des Design pattern (notamment dans le package io) alors qu'en c++ d'aprés mes souvenirs cela n'est pas le cas et dans Qt et Gtk j'ai un gros doute aussi quand à l'api windows.....

.Net, Gtk et Qt n'ont pas ce genre de problème.

Replaçons les choses dans leur contexte ce que tu cites sont des choix techniques. Avec ce scénario C++/Qt indéniablement il n'y a pas photos.

[Luc Hermitte]

Oh! Du troll ...

??? Ce n'est pas parce qu'une conception repose sur des design patterns qu'elle sera de meilleure qualité, cf les variables globales qui se déguisent en singletons.
Ensuite, sans creuser profond, les template methods ont envahi les flux surchargés (comme dans overbloated) du C++, les stratégies qui enveloppent des adaptateurs aussi, et la substituabilité (LSP) n'est pas en reste. Ils sont même itérables ce qui permet d'appliquer std::copy, std::transform et autre algorithmes pour peupler des conteneurs, ou même recopier à la volé vers un autre flux.

Si tu cherches de la conception dans le C++, regarde la STL historique, ou mieux les cours d'algorithmique d'A. Stepannov.

Qt me parait bien vieux, et à supposer qu'il ait beaucoup pris au Java, il le lui rend (cf Jambi). Ce qui n'empêche pas que je suis bien plus attiré par adobe.ASL même si ce n'est pas encore prêt pour de la production. A défaut de s'imposer, j'espère que cela inspirera suffisamment les prochains frameworks IHM (quelque soit le langage) pour que l'on puisse enfin prendre du recul dans le code.

[FloMo]

si c'est un travail de graphiste alors en java ou c++ cela ne change rien.

Hormis en terme de performances, et donc de fluidité et indirectement de confort de l'utilisateur.

Tu peux trés bien mettre ta casquette de graphiste et faire des interfaces qui ressemblent à ce que tu veux

Si je peux éviter de perdre du temps à réinventer la roue, je le fais.

Qt cela vaut bien une cacahuette, cela ressemble à du vieux mfc qui a muté en gtk puis qui a muté qui a muté pour voir aujourd'hui quelque chose qui ressemble à du code java c'est à dire enfin exploitable, plaisant avec un degré de configuration/intégration qui ne paralyse pas.

En résumé Qt apporte au C++ :
- l'aspect simple et efficace du Java, (tout en gardant la souplesse du C++)
- l'efficacité des interfaces natives de chaque plateforme.

En quoi le fait d'utiliser c++/qt ou java va permettre de gérer un imprévu ? ce sont des langages rien de plus qui traduise un travail d'une conception. Pis exploser les délais reléve d'une erreur de conduite de projet ou d'une mauvaise évaluation de scénarios pas du langage plus des programmeurs.

Si tu utilises Qt et le C++, sachant que l'interface est souple et optimisée, tu as une plus grande liberté car pas de contraintes de performances. Du moins, rien de catastrophique.

Ce qui aide aussi énormément, c'est le support Nokia pour les applications commerciales : leurs développeurs sont vraiment excellents. Chaque problème a très rapidement sa solution. C'est une force non-négligeable.

A cela s'ajoute le fait que Qt utilise le C++, ce qui donne plus de facilité d'accès aux bibliothèques tierces.

Je parlais de conception voilà dans le framework java il y a plus souvent de recours à des Design pattern (notamment dans le package io) alors qu'en c++ d'aprés mes souvenirs cela n'est pas le cas et dans Qt et Gtk j'ai un gros doute aussi quand à l'api windows.....

Qt est basé sur l'architecture model-view-delegate : développement rapide et efficace.

[hegros]

??? Ce n'est pas parce qu'une conception repose sur des design patterns qu'elle sera de meilleure qualité, cf les variables globales qui se déguisent en singletons.

La conception sera surement de meilleure qualité cela ne garantit en rien une implémentation de qualité là encore java me semble plus appeler à éviter justement les variables globales que le c++ par exemple.

Merci pour toutes ces précisions FloMo.

[FloMo]

Merci pour toutes ces précisions FloMo.

Pas de soucis.

[Luc Hermitte]

En quoi ? Ce sont deux choses différentes. Une personne avec les mauvaises habitudes de conception fera les mêmes erreurs quelque soit le langage. Que l'erreur soit une variable globale, ou un singleton, c'est exactement la même erreur: l'introduction d'un couplage indésirable.

S'il y a une chose que je concède volontiers, en terme de conception, ce sont les interfaces. Elles cassent le mythe de OO == réutiliser du code. Comme les petites roues, cela permet d'apprendre à tenir la route, à ressentir le LSP à défaut de le comprendre (ce ne sont pas les interfaces qui empêcheront d'hériter d'une Liste pour définir une ListeTriee). Après, on peut passer au pattern NVI (Non Virtual Interface) pour embarquer contrats et comportements aux interfaces.

[el muchacho]

En ce qui concerne C++, je ne pense pas qu'il existe, à ce jour, un langage digne de le remplacer.

Connais-tu le langage D ? Mon avis est qu'il peut avantageusement remplacer C++ dans 90% des cas. Bien sûr, ce n'est que mon avis...

[Alp]

Connais-tu le langage D ? Mon avis est qu'il peut avantageusement remplacer C++ dans 90% des cas. Bien sûr, ce n'est que mon avis...

Tu peux argumenter ?

J'aimerais surtout que tu m'expliques pourquoi il n'a depuis le temps pas de succès ?

[Captain_JS]

Par ces temps de crise c'est surtout un dérivé qui marche bien : le système D

[screetch]

Tu peux argumenter ?

J'aimerais surtout que tu m'expliques pourquoi il n'a depuis le temps pas de succès ?

L'utilisation de bibliotheques C en D est chiante, et encore pire pour du C++.
Il n'y a pas d'IDE valable, meme si il y a quelques trucs bien (je ne compte pas vim et emacs hein)
pas de compilo sur toute les plates formes
En revanche, D a quelques avantages certains par rapport au C++
deja, les templates fonctionnent sur des chaines litterales, ce qui permet de compiler tes propres regexp en statiques ou ce genre de chose (de meme avec les flottants)
la syntaxe des templates a été revue pour plus de lisibilité

en théorie c'est juste mieux, mais comme en pratique c'est incompatible, les gens s'en sont sans doute detournés

[Alp]

En C++ on peut utiliser des templates sur des chaînes littérales mais l'utilité est assez réduite.

Mais il y a quelques trucs bien.

De là à dire que c'est mieux que C++.

[HanLee]

J'aimerais surtout que tu m'expliques pourquoi il n'a depuis le temps pas de succès ?

Il y a un biais dans la question, les qualités d'un langages seul ne suffisent pas à garantir un succès.

[koala01]

Désolé de remonter un HS...

Je fais un peu de HS mais dans ce cas précis pourquoi vouloir porter le code c.a.d de COBOL vers un autre langage ?

Si ça marche sur des roulettes sous COBOL pourquoi porter du code sous Java ou .NET ?
Pourquoi chambouler ce qu'on a mis des années à pérenniser ?
Je n'en vois pas l'intérêt en plus COBOL s'integre sans doute parfaitement avec les grands systèmes ( je vous dis tout de suite je n'y connais rien en COBOL ).
Et puis Java et .NET coté transactionnel c'est pas forcément adapté parce que c'est trop lourd pour tourner sur MainFRame...

Le fait est que, ce n'est pas parce que l'on dispose de 10, 15 ou même 50 ans de recul avec un langage que l'on a *forcément* la réponse à tous les problèmes qui sont susceptibles de se présenter...

Comme, malgré tout, les années de développement sont une "base de connaissance" qu'il ne faut pas négliger (Ah oui, pour telle partie, j'ai déjà quelque chose dans la manche ), mais que l'interfaçage avec un autre langage n'est pas forcément coton à mettre en place (peut etre un peu plus avec .NET qu'avec un autre, vu l'existance de la couche COBOLE.Net) on a finalement le choix entre continuer à utiliser le langage "historique" ou... assurer le portage vers le "nouveau" langage que l'on a choisi.

C'est pour cela que je disais que de nombreuses boites préfèrent se "garder" sous le coude un type, payé cher et vilain, qui connait le langage "matusaleméen" historiquement utilisé (et des stagiaires payés des cacahuètes pour ce qui peut être fait dans les autres langages, histoire de "rétablir l'équilibre" )

[Furikawari]

Je comprends pas qu'il y ait encore des gens sur ce forum pour tenter d'argumenter avec les fanboys du C++...

Ca ressemble à un troll, mais vu l'acharnement et la mauvaise foi de certains, je ne pense pas que ça en soit un.

[el muchacho]

Tu peux argumenter ?

J'aimerais surtout que tu m'expliques pourquoi il n'a depuis le temps pas de succès ?

Je pourrais te l'expliquer si je savais ce qui fait le succès d'un langage. Or je crains que personne ne le sache vraiment.

Mais je pense que l'un des problèmes du langage D est qu'il est en constante évolution et développé par UN seul homme qui n'a pas l'intention d'abandonner la charge, ni du langage, ni des librairies (jusqu'à il y a peu, A. Alexandrescu, l'auteur de "Modern C++ Design", s'est joint au design du langage et des librairies). Cela n'incite pas des sociétés commerciales à lancer le développement d'un environnement de développement professionnel autour du langage.
Ceci étant, malgré cela, la popularité du langage est en croissance (http://www.tiobe.com/index.php/paperinfo/tpci/D.html), 12e entre Ruby et PL/SQL au classement Tiobe , ce qui est assez remarquable, même s'il n'atteint pas encore la masse critique nécessaire pour être un acteur majeur dans le domaine des langages système.

Quand à la supériorité de D sur C++, je pense qu'il ne permet pas de faire plus de choses que C++. P-ê même que D est légèrement moins universel que C++ (d'où mon 90%, mais ça reste à démontrer). Mais ce qui est certains, c'est que les 90% en question peuvent être réalisées de façon nettement plus simple, plus rigoureuse et plus sûre qu'en C++. Ce simple tableau est assez éloquent: http://www.digitalmars.com/d/2.0/comparison.html (en particulier les commentaires agrémentés d'exemples, il suffit de suivre les liens). La syntaxe des programmes D est bcp plus régulière et lisible que C++ (en fait d'une lisibilité comparable à Java). Mais surtout, le langage est développé et implémenté par qq qui connait intimement le C++, ses qualités et ses défauts, puisque ça fait 15 ans qu'il développe aussi des compilos C++ (en fait, le back-end du compilo C++ et de D sont le même).
En ce qui concerne les templates, les deux apports majeurs de D sont le static if et les expressions is (même si Boost a bien amélioré les choses du coté de C++).
Mais encore une fois, la qualité d'un langage ne fait pas son succès. Il y a des tas et des tas d'autres paramètres à prendre en compte,sur lesquels D est sans doute déficient. Sinon, Java n'aurait pas autant de succès.

[FloMo]

Qt me parait bien vieux

Juste pour faire l'entorse aux idées reçues et remettre Qt à sa place, allez voir les blogs de Qt Software.

[Luc Hermitte]

^^'
Je traduis ma phrase: suffisamment vieux pour ne pas être un vulgaire clone de Java.
Après, c'est de l'IHM avec un passif orienté portabilité (d'où le NIH), et les IHM ne m'intéressent pas. Pour l'instant, seul Adobe.ASL suscite un peu d'intérêt chez moi.