Discussion :

[gorgonite]

... Alors qu'en Java, ecrivez votre appli en swing, et il sera facilement maintenable par n'importe quel developpeur GUI Java.

faut dire que c'est vrai... surtout si l'on fait du swt

[FloMo]

Le problème c'est que ST4 n'est pas standard. Et c'est ça le pb de C++. La bibilothèque standard est pauvre!!

C'est vrai.

, et quand il y a pas de standard, on met plus de temps à maintenir du code ecrit dans une bibliothèque qu'on ne connait pas (il est peu probable par exemple que vous puissiez rapidement maintenir un code ecrit en MFC, étant donnez que votre biblio est QT4).

C'est une question de choix. Je ne connais pas MFC. Après, le problème se pose plus au niveau de la structure du programme. Si l'interface est bien séparée des traitements, il n'y a pas de problèmes de migration. Il suffit de lire la documentation.

Alors qu'en Java, ecrivez votre appli en swing, et il sera facilement maintenable par n'importe quel developpeur GUI Java.

Evidemment, vu que le choix est très restreint.

La force du C++, c'est aussi le large panel d'outils qu'il fournit. Si tu as du code qui gère les traitements à côté d'un code qui gère la GUI, tu n'auras aucun problème à changer de GUI.
La souplesse du C++ lui permet de ne pas faire ce que fait Java : "Test it everywhere". Je viens de passer une application C++/Qt4 de GNU/Linux vers Windows : même pas mal ! Le rendu est natif, le temps d'exécution très correct et même si j'avais quelque-chose à modifier dans le code, s'aurait été fait en 2 minutes grâce au directives de compilation.

[Luc Hermitte]

Il a surtout une approche beaucoup plus simple et différent de l'objet que le C++ (je ne me prononce pas sur Eiffel que je ne connais pas) :

• Méthode virtuelle par défaut.
• Pas d'héritage multiple.
• Notion de constructeur de copie quasi-absente, au profit de l'utilisation de classe immuable.
• Pas de surcharge des opérateurs (mais est-ce bien de l'objet ?)

A mon sens c'est plus une différence de philosophie et on ne peut pas vraiment dire que l'un est plus complet que l'autre ou plus aboutis...

Rajoute l'absence :
- de support natif de la programmation par contrat (le C++ le permet nativement, mais avec de l'huile de coude -- tout comme pour les interface -- Eiffel et D la supporte avec des mots clés dédiés) qui soit toujours valable sur plus d'une "interface"
- d'héritage de pure réutilisation (i.e. qui n'implique pas la subtituabilté au sens du LSP)

Le problème des opérateurs me parait à rapprocher à l'absence de sémantique de valeur sur les objets en Java. Sans être directement lié à l'OO, c'est tout autant connexe que le problème du polymorphisme paramétrique.

Sinon oui, ce sont des langages avec des philosophies et idiomes bien différents pour le reste. N'empêche on ne me fera pas démordre que le langage Java est complètement bridé : la simplification n'est pas qu'au niveau de la syntaxe, elle l'est également au niveau des concepts supportés. C'est un choix différent.

[adiGuba]

Rajoute l'absence :
- de support natif de la programmation par contrat (le C++ le permet nativement, mais avec de l'huile de coude -- tout comme pour les interface -- Eiffel et D la supporte avec des mots clés dédiés) qui soit toujours valable sur plus d'une "interface"
- d'héritage de pure réutilisation (i.e. qui n'implique pas la subtituabilté au sens du LSP)

Je n'ai pas dit que cette liste était complète

Pour la programmation par contrat, je ne connais pas ce domaine mais il existe JContractor (par contre j'ignore la quantité d'huile de coude nécessaire )

N'empêche on ne me fera pas démordre que le langage Java est complètement bridé : la simplification n'est pas qu'au niveau de la syntaxe, elle l'est également au niveau des concepts supportés. C'est un choix différent.

Je suis tout à fait d'accord sur la dernière phrase

Par contre je le suis moins sur le coté "bridé"... mais en même temps on ne doit pas avoir les mêmes besoins/restrictions

a+

[Mat.M]

Le problème c'est que ST4 n'est pas standard. Et c'est ça le pb de C++. La bibilothèque standard est pauvre!!, et quand il y a pas de standard, on met plus de temps à maintenir du code ecrit dans une bibliothèque qu'on ne connait pas .

La bibliothèque standard du C++ est pauvre par essence.
Si on veut avoir une bibliothèque graphique qui gére souris et bouton après cela dépend de l'OS ; tu parles de MFC , MFC utilise en majeure partie les fonctionnalités de l'OS.
Quant à réecrire du code et que cela entraine une perte de temps c'est discutable; les choses toutes faites comme Java c'est bien mais on ne peut pas toujours optimiser....

Donc à choisir pour un débutant qui veut faire de la programmation son métier: le Java ou le C# s'il a la fibre M$, à moins de vouloir travailler dans des domaines spécifiques (jeux, temps réel, ...) où le C++ domine.

oui tu as raison mais Java ça ne me passionne pas....c'est trop "préfabriqué" pour moi..
Non pas que tu ne puisses pas faire des choses puissantes avec ni des projets complexes mais bien souvent tu manipules des choses qui ne sont pas tangibles...

[Luc Hermitte]

Pour la programmation par contrat, je ne connais pas ce domaine mais il existe JContractor (par contre j'ignore la quantité d'huile de coude nécessaire )

Disons, pour être honnête, que repprocher l'absence de support de la PpC en Java, c'est comme reprocher l'absence de GC en C++.
Dans les deux cas il existe des solutions non standard.

PS: pour jContractor, je reste sceptique quant à comment hériter de plusieurs contrats comme l'on hérite de plusieurs interfaces. Je sais qu'il existe d'autres solutions de type pré-processeur.

[phpmad]

Quant à réecrire du code et que cela entraine une perte de temps c'est discutable; les choses toutes faites comme Java c'est bien mais on ne peut pas toujours optimiser....

Rien ne t'empêche de réecrire swing à ta manière, comme IBM avec SWT...on se revoit dans 10 ans.

Java = sobriété, C++ = ivresse

sinon pour les jeux apparement C++ va devoir céder sa place à C#...non ?

[gorgonite]

Rien ne t'empêche de réecrire swing à ta manière, comme IBM avec SWT...on se revoit dans 10 ans.

je pense toutefois que ce projet peut amener de bonnes choses...

Java = sobriété, C++ = ivresse

ce genre de devise sans argumentation est... inutile, et vraiment inattendue

sinon pour les jeux apparement C++ va devoir céder sa place à C#...non ?

ça reste à voir...

[Epistocles]

oui tu as raison mais Java ça ne me passionne pas....c'est trop "préfabriqué" pour moi..
Non pas que tu ne puisses pas faire des choses puissantes avec ni des projets complexes mais bien souvent tu manipules des choses qui ne sont pas tangibles...

permettez-moi de donner l'avis d'un débutant en Java, moins de 6 mois, après plus de 10 ans en C.

la première chose qui m'a perturbé, c'est l'absence de pointeurs. Quand on a mis tant de temps à faire rentrer dans son petit crâne la gestion mémorielle du langage de bas niveau, l'auto-gestion de java semble un peu louche.

et puis on découvre les pointeurs cachés ... ou lorsque l'argument objet équivaut à *objet
manque juste les doubles pointeurs, m'enfin bon

le problème, c'est le concept même de la programmation objet. c'est un concept fabuleux, mais qui dérange fortement une race particulière de programmateurs : la mienne, celle qui a plus de 30 ans, qui a vu naître l'informatique, qui a appris avec le basic, l'assembleur, qui a dû taper du code pendant des heures pour jouer à son premier jeu, qui a cru que la révolution était en marche quand il a eu son premier ordi avec un DISQUE DUR (waouh), et qui a appris à gérer un ordi à la console, pas à l'interface graphique (je clique, je clique).

bref, ceux que ça énerve de se voir dépasser par les évenements, qui ont l'habitude de tout contrôler, de tout comprendre et de tout savoir à l'intérieur de l'architecture d'un code, et qui là se trouvent en quelque sorte : "transposés du statut de créateur à celui d'utilisateur d'un système".
Java a des librairies nettement plus fournies, ce qui incite à davantage s'en servir, donc à davantage être utilisateur de code tapé par d'autres, donc ne pas contrôler à la perfection certaines portions de ses propres applications, mais faire davantage confiance aux autres développeurs.


Parce qu'ils se trouvent confrontés à une autre génération : celle de jeunes qui ont entre 15 et 20 ans aujourd'hui. ils n'ont pas connu Coluche ni Téléphone et considèrent tout ce qui est en noir et blanc comme préhistorique. ces jeunes-là ont grandi dans le concept de la POO que leurs aînés ont créée, et nagent dedans comme des poissons dans l'eau. Ils sont plus vifs et comprennent plus vite, plus instinctivement, certaines notions que les vieux mettent un certain temps à intégrer .. pour eux, vouloir contrôler la réallocation mémoire manuellement dans une application de 20 k lignes de code, c'est comme vouloir contrôler les interruptions système pour un vieux (comprenez, contrôler les flux éléctriques au niveau matériel sur la carte-mère en fonction de la première couche par exemple). ça leur semble idiot, et ça ralentit le développement des couches supérieures, puisqu'on ne peut pas tout faire en même temps.

La solution, elle est là. La question n'est pas "quel langage pour quel type d'application", mais "quel langage pour quel développeur". Celui qui préfère contrôler le bas niveau d'architecture préferera le C++ et maîtrisera à la perfection chaque partie de son code et de son langage, optimisant au maximum chaque interaction de l'application avec l'environnement. Celui qui préferera contrôler le développement de haut niveau d'architecture préferera Java et développera plus vite et de façon plus extensive ses applications, en se basant sur un bas niveau écrit par des spécialistes dans chaque domaine, pour optimiser l'interaction de l'applcaition avec l'utilisateur.

Au final, chacun de ces 2 langages a des spécificités que l'autre n'a pas, et chacun représente une vision du développement qui est indispensable à la bonne pratique du code

[sacofan]

Il est rare de trouver du java coté serveur dans le secteur bancaire.

[the-gtm]

La solution, elle est là. La question n'est pas "quel langage pour quel type d'application", mais "quel langage pour quel développeur". Celui qui préfère contrôler le bas niveau d'architecture préferera le C++ et maîtrisera à la perfection chaque partie de son code et de son langage, optimisant au maximum chaque interaction de l'application avec l'environnement. Celui qui préferera contrôler le développement de haut niveau d'architecture préferera Java et développera plus vite et de façon plus extensive ses applications, en se basant sur un bas niveau écrit par des spécialistes dans chaque domaine, pour optimiser l'interaction de l'applcaition avec l'utilisateur.

Optimisation :
Rule#1 don't do it
Rule#2 (experts only) don't do it yet

(en VF : l'optimisation règle#1 n'en faites pas, règle#2 (pour les experts) n'en faites pas pour l'instant)

Pour développer un peu : dans la plupart des sociétés le développeur moyen a en moyenne 0 années d'expérience. Dans ces conditions laisser ce genre d'individus (je me mets dans le lot) gérer la mémoire à la main, définir des hiérachies de classes sur 15 étages avec 12 niveaux d'abstraction, c'est comme donner une mitraillette à un singe.

Quand on voit le résultat en Java, beaucoup font des "optimisations", du genre faire des pools d'objets, appeler le GC toutes les deux lignes, faire un cache d'Integer etc. En C/C++ je n'imagine même pas le désastre ...

Bien d'accord avec toi Epistocles

[eclesia]

Je crois que le sujet est bien avancé, aussi bien les points positifs que negatifs de chacun des deux. je ne donc pas remettre en cause tout ce qui a été dit (par des plus compétents que moi en général).

Et bien jai choisi le java, je connais aussi le C pour microcontroleur.

Je vois le java comme une surcouche abstraite (d'ou ca portabilité et ca necessité d'une JVM) par rapport au C/C++. Java est la pour nous eviter de reecrire le code selon l'os, et java s'efforce de ne pas tenir compte du materiel, c'est une liberté. Au contraire quand je developpai en C pour des PIC16F872 ma programmation était directement lié au composant, donc des fois pas tres "algorithmique" mais parfaitement adapté a son environnement.

Il faut que ces deux langages existent, il n'y a pas de C versus Java qui tienne.

[Fabrice ROUXEL 1]

Thifauv a écrit en page1:

Je pense aussi qu'il faut apprendre les deux, mais dans un certain ordre:

Java en premier puis C++

C'est marrant j'aurais plutôt dit le contraire.

Je suis passé par le C et le C++ pour m'orienter ensuite vers Delphi et C#.
Je pense que C++ permet de bien appréhender les notions de types, de blocs mémoires, de pointeurs etc...

C et C++, de part leur précision, force la compréhension du code.
Combien de fois au début me suis-je demandé en delphi comment est transmis un record, un objet, un entier (valeur ou adresse?).
Idem en ce qui concerne les tableaux.

D'ailleurs, pour effectuer des traitements de chaines, je transtype toujours les strings en pchar pour me retrouver dans un contexte 'C'.

Et le constructeur de recopie, la forme canonique de Coplien: concepts absent en Delphi.

Pour le développement à bas niveau C et C++ resteront les références.


PS/ Le Java? quelle horreur! Ce langage n'a jamais su me convaincre.
@+

[broumbroum]

je n'ai jamais programme de C++ mais il en ressort que la plupart des jeux tourne en C. Toutefois apres avoir testé le projet Jake2, le portage de Quake2 en Java2, je pense que Java est maintenant assez evolué pour dépasser le C++.
Certes il n'est pas évident de trouver de bonnes applis en Java2 encore aujourd'hui, cependant il est plus prudent de choisir la plate-forme qui promet le plus de perennité. À partir de là, je choisis naturellement Java2, car le developpement des nouvelles technologies et la recherche se tournent de plus en plus vers les nouvelles plate-formes de dev, tel Java2 ou le Web 2.0

[fasteez]

dans l'absolu, un bon développeur connaitra c, c++, ada, java, c#, javascript, php, ocaml, lisp, scheme, et des implantations en assembleurs + des notions de compilations, de grammaire, de sémantique.. à partir de la on arrête de cherche quel langage est le meilleur, on implante le programme spécifié avec le langage imposé et les ressources présentes.

[kpouer]

La solution, elle est là. La question n'est pas "quel langage pour quel type d'application", mais "quel langage pour quel développeur". Celui qui préfère contrôler le bas niveau d'architecture préferera le C++ et maîtrisera à la perfection chaque partie de son code et de son langage, optimisant au maximum chaque interaction de l'application avec l'environnement. Celui qui préferera contrôler le développement de haut niveau d'architecture préferera Java et développera plus vite et de façon plus extensive ses applications, en se basant sur un bas niveau écrit par des spécialistes dans chaque domaine, pour optimiser l'interaction de l'applcaition avec l'utilisateur.

Au final, chacun de ces 2 langages a des spécificités que l'autre n'a pas, et chacun représente une vision du développement qui est indispensable à la bonne pratique du code

Je pense que le type d'application entre tout de même en compte un petit peu. Le C++ par exemple sera plus adapté pour coder du bas niveau, genre codec, driver, ce genre de choses (et encore java s'en sort extrêmement maintenant pour pas mal de choses, souvent un algo implémenté de manière identique sera plus performant en java du fait du compilateur JIT. Il est possible. de faire mieux en C++ mais au prix d'un travail d'optimisation supplémentaire). Mais souvent ce qui ralenti un programme n'est pas en lui même mais a l'extérieur (attente IO, entrées utilisateurs), et dans ce cas quelque soit le langage, on y peut pas grand chose.
Java a un autre avantage, c'est un gros travail de standardisation de Sun dans beaucoup de domaines, le J2EE. Chez nous par exemple on fait des servlet SIP pour un système téléphonique. Le gros avantage est que le container SIP gère le clustering chose qu'il aurait été bien plus complexe si on avait du la programmer nous même

Il est rare de trouver du java coté serveur dans le secteur bancaire.

Euh t'as fait beaucoup de banques ? Apparament non.

Optimisation :
Rule#1 don't do it
Rule#2 (experts only) don't do it yet

(en VF : l'optimisation règle#1 n'en faites pas, règle#2 (pour les experts) n'en faites pas pour l'instant)

Pour développer un peu : dans la plupart des sociétés le développeur moyen a en moyenne 0 années d'expérience. Dans ces conditions laisser ce genre d'individus (je me mets dans le lot) gérer la mémoire à la main, définir des hiérachies de classes sur 15 étages avec 12 niveaux d'abstraction, c'est comme donner une mitraillette à un singe.

Quand on voit le résultat en Java, beaucoup font des "optimisations", du genre faire des pools d'objets, appeler le GC toutes les deux lignes, faire un cache d'Integer etc. En C/C++ je n'imagine même pas le désastre ...

Bien d'accord avec toi Epistocles

Ben si tu donne Java a un singe, c'est sur tu risques pas ta vie mais le résultat est pas mieux qu'avec une mitraillette

[knoum]

...

Euh t'as fait beaucoup de banques ? Apparament non.

...

Cette affirmation de "sacofan" ma donné aussi a sourire.

[eclesia]

dans l'absolu, un bon développeur connaitra c, c++, ada, java, c#, javascript, php, ocaml, lisp, scheme, et des implantations en assembleurs + des notions de compilations, de grammaire, de sémantique

tu tire vraiment large, la connaissance c'est plutot VB/VBA, php, C++, java, et encore cela depend des cursus, on ne voit pas le C++ quand on aborde le java et vise versa. certain bts mettent un point sur l'ASP et le delphi, et laisse de coté java/C++/VB.
mais quand a citer ada,ocaml,lisp,scheme .... je ne les connais que de nom et je pourrais pas meme affirmer qu'il s'agit de langage.
Que dire de l'assembleur? il ne faut pas rever on ne l'apprend plus du tout en section informatique.

Une majorité de nos stages de BTS (option developpeur) se sont passé dans des boites qui utilisés VB.net

[robert_trudel]

tu tire vraiment large, la connaissance c'est plutot VB/VBA, php, C++, java, et encore cela depend des cursus, on ne voit pas le C++ quand on aborde le java et vise versa. certain bts mettent un point sur l'ASP et le delphi, et laisse de coté java/C++/VB.
mais quand a citer ada,ocaml,lisp,scheme .... je ne les connais que de nom et je pourrais pas meme affirmer qu'il s'agit de langage.
Que dire de l'assembleur? il ne faut pas rever on ne l'apprend plus du tout en section informatique.

Une majorité de nos stages de BTS (option developpeur) se sont passé dans des boites qui utilisés VB.net

pour de l'informatique de gestion oui on voit vb...... sinon peu d'intéret

[fasteez]

mais quand a citer ada,ocaml,lisp,scheme .... je ne les connais que de nom et je pourrais pas meme affirmer qu'il s'agit de langage.

et pourtant ce sont de vrais langages et pas des moindres, ada est cantonné à sa niche mais je me rappelle c'est ada qui m'a appris à vraiment comprendre les interêts de java ( interface, encapsulation, généricité, accès mémoire restreint, surcharge aussi je crois )

caml en tant que langage fonctionnel rebute, je suis une pine finie, mais leur facon de penser est tout sauf mauvaise, ca te debouche les yeux d'une certaine facon.

lisp et scheme eux c'est un peu plus spécial.. c'est des langages à langage .. fini la machine , 100% de symbolique donc c'est bon pour l'intellecte et pour mieux penser son programme.

Que dire de l'assembleur? il ne faut pas rêver on ne l'apprend plus du tout en section informatique.

bah hmm d'une certaine manière quand tu fais du C en général on te parle de choses qui débordent sur l'assembleur, mais pondre un protocol d'appel de fonction c'est bien aussi ^^.

Une majorité de nos stages de BTS (option developpeur) se sont passé dans des boites qui utilisés VB.net

là c'est hors de mes connaissances je suis à la fac et nos stages sont pas du tout sur les même thèmes j'ai l'impression. d'ailleurs quels genre de développement sont fait via vb.net ? ( vu qu'avec .net le langage n'influe pas trop sur les possibilités ça peut aller du client lourd à l'application coté serveur )

pour finir je pense que quand t'as vu tout ca tu penses plus du tout un programme de la même manière u_u;
les cours de sémantique opérationnelle m'ont perverti lol


peace