Discussion :

[Manolo]

Ce que tu dis n'est pas faux Tifauv en C++ on peut prendre de mauvaises habitudes !
Mais je pense que le C++, en ayant fait du C avant, est beaucoup plus rapide à mettre en oeuvre que le Java.

[laffreuxthomas]

J'y vais ausi de mon grain de sel :

les applets java ne m'intéressent pas, pour faire du Web j'utilise PHP. Donc ma question se situe uniquement au niveau applications...

Les applets s'exécutent côté client. Donc tu ne peux pas les remplacer par des PHP, mais par du JavaScript. Ce sont les Servlets et JSP qui jouent sur le même tableau que les PHP.

Sinon je pense que C++ est sur la pente descendante pour l'informatique de gestion. Reste l'info industrielle.

Enfin, l'avenir (et le présent !) des applications distribuées est dans les nouvelles techno
- parcequ'elles permettent de s'affranchir des détails techniques de communication -> on se concentre sur la prog métier.
- parceque la démarche des éditeurs est d'en faire des standards

Et voilà pour info un post qui traite déjà du sujet : http://www.developpez.net/forums/viewtopic.php?t=16969

Thomas

[gl]

Sinon je pense que C++ est sur la pente descendante pour l'informatique de gestion.

C'est ce qu'il se disait de Cobol il y a deja pas mal d'annee. Resultat c'est encore utilise, ca recrute meme encore un peu et certaines personnes se voient obligees de s'y mettre pour telle ou telle mission.
Pour resumer, il faut se mefier des technos sur la pente descendante, certaines mettent quelques dizaines d'annees avant d'etre relegue au rang de simple curiosite.

[laffreuxthomas]

oui en fait c'est tout à fait ce que je veux dire : C++ va vivre le même sort que Cobol. On a le temps de voir venir mais plus le temps passera et moins ça sera intéressant.

[Tifauv']

Je ne suis pas tout à fait d'accord. Je pense que Java devrait se développer pour les applications non-OS et être utilisé quand on n'a pas besoin de vitesse pure.

Mais pour tout ce qui est développement système, le C/C++ est le seul langage utilisable (avec un peu d'assembleur éventuellement). Et pour le moment, aucun langage n'est capable de le remplacer. Donc, le C/C++ devrait durer encore un bon bout de temps.

Par contre, c'est une hérésie que Cobol soit encore utilisé.

[diopahmadou]

Je ne suis pas tout à fait d'accord. Je pense que Java devrait se développer pour les applications non-OS et être utilisé quand on n'a pas besoin de vitesse pure.

Mais pour tout ce qui est développement système, le C/C++ est le seul langage utilisable (avec un peu d'assembleur éventuellement). Et pour le moment, aucun langage n'est capable de le remplacer. Donc, le C/C++ devrait durer encore un bon bout de temps.

Par contre, c'est une hérésie que Cobol soit encore utilisé.

Disons que si vous avez l'âme d'un pirate et que vous etes orienté programmation systéme mieux vaut se tourner vers le C/C++ cependant il faut etre baléze en programmation (comme écrire le noyau d'un OS)! par contre pour les développeurs orientés appli entreprise, Java, est à mon humble mon avis, plus complet et plus facile à mettre en oeuvre que C/C++.

[EtherOS]

Sujet :<<C++ vs Java>>

--> C/C++

le Langage C/C++ est facile a utiliser ,plus comprehensible et vraiment efficace.Il est un langage de base et de haut niveau pour les reseaux,la securite et le developpement .De plus, lorsqu'on regarde par exemple le Framework Qt x.xx x <=10 du C++, on voit les capacites du C++ encor plus clair avec l'impact dans tous les domaines satellites, mobiles, reseaux, jeux 3D,2D et Web , beaucoup d'autres choses interessantes.

--> Java (EE,FX,etc...)
Celui-ci est plus portable, evolue et efficace dans le developpement d'applications mobile, satellite, commande des voitures , serveurs ,GPS, bref logiciels de haut niveau . De plus , tres bon dans la programmation reseau et Web.
Bref le Java reste toujours le plus utilise pour des projets de haut niveau , Hi-TECH

Excusez moi pour la redaction orthographique mal faite (pb de mon ordinateur)

Merci

[Grimimi]

EtherOS, personnellement, je ne suis pas d'accord, je trouve que le langage C++ est vraiment un langage drastiquement complexe à apprendre notamment à toutes les possibilités qu'on lui à découvert en détournant d'autres de ces possibilités. Ceci dit, je ne critique pas ce qu'il est possible de faire avec C++.

[Luc Hermitte]

-1 pour "C/C++".
Le C++ est déjà assez compliqué à lui tout seul, quand on l'utilise en mode "C with classes", c'est une catastrophe à maintenir. C et C++ sont deux langages à part entière, chacun avec ses bonnes pratiques (la faute aux exceptions). Et ça, c'est le sujet d'un autre troll planqué dans le forum C ou celui C++, je ne sais plus.

[jabbounet]

Sujet :<<C++ vs Java>>

--> Java (EE,FX,etc...)
Celui-ci est plus portable

Merci

Dans la limite ou un jvm existe sur la plateforme pour laquelle tu souhaite faire ton soft....
Ce qui nécessite souvent un compilateur C pour que la jvm puissent déjà y etre portée elle même.

[rimram31]

J'avoue méconnaitre le C++, a peu près 10 ans de C et 10 ans de Java, je n'ai jamais réussi a me faire au C++, déjà dès son arrivée et encore moins après m'être essayé a Java, Python ... Je trouve que le C++ est le pire langage que l'on puisse imaginer pour faire comprendre l'objet car il ne va pas "a l'essentiel".

Maintenant, selon le domaine d'application, on a guère le choix on prendra ou le C++, ou Java (ou un autre langage encore ...), faire du "système" en Java serait une hérésie comme faire du web en C++ du temps perdu, par contre la question peut se poser entre les deux où ils pourraient être "en compétition".

Toutefois, même si la technologie ne vaut que parce que l'on en fait, il est une sorte de "philosophie" d'un langage qui va influer sur les habitudes que l'on prend en l'utilisant. De son origine, destiné a permettre le contrôle d'une multitude d'équipements, la notion de "contrat" (interface) est prépondérante en Java et largement utilisée, elle est bien entendu possible en C++ mais moins "naturellement" mise en oeuvre. Dans une relation client/fournisseur entre deux modules de code, Java pousse a s'intéresser a ce dont le client a besoin, pas tout ce que le fournisseur peut fournir.

On parle de portabilité et non plus de compatibilité (s'amuser a comparer l'approche de Sun de l'époque avec celle de Microsoft :-)) Je n'ai pas a "porter" un programme Java puisqu'il est conçu d'origine pour l'être et invite le développeur a le généraliser dans son architecture.

[Bousk]

la notion de "contrat" (interface) est prépondérante en Java et largement utilisée, elle est bien entendu possible en C++ mais moins "naturellement" mise en oeuvre. Dans une relation client/fournisseur entre deux modules de code, Java pousse a s'intéresser a ce dont le client a besoin, pas tout ce que le fournisseur peut fournir.

Euh... pardon ?
Quand tu passes en C++ tu débranches une partie de cerveau ?
En quoi JAVA pousserait plus à l'utilisation d'interface que C++ ?

[deadalnix]

De son origine, destiné a permettre le contrôle d'une multitude d'équipements, la notion de "contrat" (interface) est prépondérante en Java et largement utilisée, elle est bien entendu possible en C++ mais moins "naturellement" mise en oeuvre.

Je te conseille de regarder Eiffel ou D pour savoir ce que sont des contrats.

[aristide_b]

Hormis l'aspect purement utilisateur, ne faut-il pas aussi penser aux méthodes d'analyse ? je pense à Hood, Strood, Grady Booch ?
Le "implement" de java n'est-il pas un contournement de classes abstraites que l'on pourrait hériter si on accepte l'héritage multiple ?
L'héritage multiple, par ailleurs, n'est-il pas une vision plus réelle du monde ?

[Luc Hermitte]

Hormis l'aspect purement utilisateur, ne faut-il pas aussi penser aux méthodes d'analyse ? je pense à Hood, Strood, Grady Booch ?
Le "implement" de java n'est-il pas un contournement de classes abstraites que l'on pourrait hériter si on accepte l'héritage multiple ?
L'héritage multiple, par ailleurs, n'est-il pas une vision plus réelle du monde ?

Je ne suis pas très fan de la dichotomie implement/inherit et préfère importe du code/sous-type pour être substituable à que Java rend mal à mon goût.

Cependant, je ne suis pas d'accord quand tu dis que l'héritage multiple serait une vision plus réelle du monde. Quand on commence à vouloir dire que pingouins et manchots sont des oiseaux, mais que les manchots ne volent pas, etc. On voit très vite les limites de l'approche OO. Même avec héritage multiple. Ce n'est pas pour rien que l'on a vu l'émergence d'approches basées sur des traits. Un des représentants qui a le vent en poupe en ce moment est l'Entity - Component - System.

[Logan Mauzaize]

Hormis l'aspect purement utilisateur, ne faut-il pas aussi penser aux méthodes d'analyse ? je pense à Hood, Strood, Grady Booch ?

Quel rapport avec C++ et Java ?

Le "implement" de java n'est-il pas un contournement de classes abstraites que l'on pourrait hériter si on accepte l'héritage multiple ?

L'absence d'héritage multiple évite tout problème lié à la recherche de l'implémentation d'une méthode. Elle est soit présente sur la classe elle-même, soit sur la classe mère. Aucun conflit possible.
C'est un choix de beaucoup de langage. Idem pour la surcharge, elle est supportée par Java, mais beaucoup d'autres langages ne l'a supporte pas car cela amène souvent beaucoup de problèmes.

L'héritage multiple, par ailleurs, n'est-il pas une vision plus réelle du monde ?

Premièrement, le principe de l'informatique c'est la modélisation, c'est-à-dire l'abstraction du monde réel. On abstrait déjà au niveau conceptuel alors dans le code, c'est encore différent.

Deuxièmement, qu'est-ce que l'héritage de l'objet dans le monde réel ? La définition la plus communément admise est "est un". Hors le principe des interface (virtuelle pure en C++) respecte ce principe. Donc l'héritage multiple de classes (non-virtuellement pur) n'est pas plus proche du monde réel.

[koala01]

Deuxièmement, qu'est-ce que l'héritage de l'objet dans le monde réel ? La définition la plus communément admise est "est un". Hors le principe des interface (virtuelle pure en C++) respecte ce principe. Donc l'héritage multiple de classes (non-virtuellement pur) n'est pas plus proche du monde réel.

Je crois en fait que cette définition est surtout un abus de langage, un raccourci un peu trop vite utilisé.

Car, si on modifiait cette définition afin de respecter l'esprit du LSP (qui est le principe de base de l'héritage publique), pour qu'elle corresponde à "est substituable à un" voir à "peut être utilisé comme un" (ce sera moins ambigu que terme substituable), on se rend compte que, dans la vie de tous les jours, une voiture peut -- effectivement -- être utilisée comme un véhicule et qu'un manchot ne peut pas être considéré comme un oiseau (bien qu'étant un ovipare ) car il lui manque une caractéristique essentielle pour être réellement un oiseau : la capacité de voler

[Logan Mauzaize]

Je crois en fait que cette définition est surtout un abus de langage, un raccourci un peu trop vite utilisé.

Car, si on modifiait cette définition afin de respecter l'esprit du LSP (qui est le principe de base de l'héritage publique), pour qu'elle corresponde à "est substituable à un" voir à "peut être utilisé comme un" (ce sera moins ambigu que terme substituable), on se rend compte que, dans la vie de tous les jours, une voiture peut -- effectivement -- être utilisée comme un véhicule et qu'un manchot ne peut pas être considéré comme un oiseau (bien qu'étant un ovipare ) car il lui manque une caractéristique essentielle pour être réellement un oiseau : la capacité de voler

A mon avis, l'abus c'est surtout de faire trop de parallèle entre le monde réel et un système informatique.

Le manchot (type), comme la poule et d'autres, sont deux oiseaux n'ayant pas la capacité de voler, quelque soit l'individu (instance). La capacité de voler (méthode / trait) n'est donc pas une caractéristique des oiseaux (membre). En revanche, "avoir la capacité de voler" (booléen) en est une mais c'est aussi le cas de tout le règne animale.
Par ailleurs tout animal ayant la capacité de voler peut la perdre temporairement ou définitivement. Il convient donc surtout de bien abstraire et borner le monde réel pour modéliser le système étudié.

Il est donc inutile de trop philosopher. Cette vue de l'esprit est aussi bien implémentée en Java qu'en C++. Je me souviens d'ailleurs très bien d'une excellente remarque d'un de mes enseignants de l'IUT : "en C++, on confond toujours composition et héritage à cause de l'héritage multiple". Les traits ont cet avantage d'apporter la composition tel qu'on l'utilise par héritage.

[AbA2L]

Java a été tiré du langage C/C++ non ? Donc c'est une façon de dire que C++ est l’ancêtre de Java...

Bref a mon avis Java et C++ sont tout les deux utiles, chaque un pour une tache spécifique

[bisthebis]

Pour ma part, ce qui me manque le plus en Java, c'est les sémantiques de valeurs (multiplier des matrices à destination d'OpenGL en Java, c'est monstrueusement lourd, par rapport au C++ où n'importe quelle bibli implémente une surcharge d'opérateurs) et, à l'inverse, le passage de primitive par référence. Devoir écrire en java "int[] VBO = new int[1];" pour simuler un pointeur C a été pour moi une insulte au bon sens, je ne m'en suis pas encore remis
Sinon, j'ai peut-être pas assez été en profondeur avec Java, mais depuis C++11/14, je trouve que la manipulation de fonctions (std::function, lambdas, etc) est un vrai régal à utiliser.

Je dirais que les seules choses que j'apprécie en Java, ce sont les IDEs d'excellente qualité (en C++ je travaille principalement avec Vim + make, donc accéder à la doc d'une fonction en un clic c'est pas aussi rapide qu'avec IntelliJ ou Eclipse ^^), encore que j'ai pas testé en profondeur VC et QtCreator, qui m'ont l'air d'être presque aussi bien en termes de refactoring.
Enfin, en Java, j'apprécie le style "homogène" du langage (quand je vois les trucs "complexes" du C++ comme les rvalues reference, je me dis que le Java est beaucoup plus facile à appréhender... même si l'absence de ces concepts est pour moi une preuve que le Java est moins efficace) et la librairie standard cohérente et polyvalente.