Le débat C++ vs Java fait toujours rage

Tags
Réseaux sociaux
0   0




Le , par aliasjcdenton, Membre du Club
Quels sont les avantages et les inconvénients respectifs majeurs des langages de programmation C++ et Java l'un vis-à-vis de l'autre ?



Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de ptah35 ptah35 - Membre chevronné http://www.developpez.com
le 17/05/2014 à 0:23
Citation Envoyé par Ubiquité Voir le message
L'un est à typage dynamique l'autre statique, ça fait un grosse différence de paradigme.
J'ai oublié ce qu'il en était pour Visual Basic avant la version 3, mais depuis cette version VB n'a jamais été ni strictement à typage statique ni strictement à typage dynamique (mais assurément faiblement typé). Avant VB.NET, il y avait un type "Variant" qui était le type par défaut d'une variable et qui pouvait contenir une valeur de n'import quel type, ainsi qu'un type "Object" qui représentait une référence à un objet de n'importe quel type (en réalité, il s'agissait d'une référence à un objet COM qui implémente l'interface IDispatch). Avec VB.NET, le langage changé, le type Variant n'avait plus de sens et a été abandonné. Le type Object a été conservé et représente une référence vers n'importe quel type de valeur (type simple via le boxing ou référence à un objet).

Via le type Variant et Object avec VB jusqu'à la version 6 et via le type Object en VB.NET, Visual Basic supporte effectivement une forme de typage dynamique, mais .NET est avant tout statiquement typé. Depuis la version 4.0, C# supporte également le typage dynamique avec le mot clé "dynamic" de manière à permettre l'interopérabilité avec COM et le Dynamic Langage Runtime.

Donc outre le fait que je ne pense pas que typage dynamique ou statique soit une grosse différence de paradigme en général, depuis 2010, cette différence n'existe plus entre VB.NET et C#.
Avatar de aektiareti aektiareti - http://www.developpez.com
le 28/07/2014 à 18:36
Citation Envoyé par aliasjcdenton Voir le message
Quels sont les avantages et les inconvénients respectifs majeurs des langages de programmation C++ et Java l'un vis-à-vis de l'autre ?

Java plus utilisé qu C++
Avatar de Sennad Sennad - Membre chevronné http://www.developpez.com
le 29/08/2014 à 14:34
Citation Envoyé par aektiareti Voir le message
Java plus utilisé qu C++
C'est quoi cet argument bidon ? ...
Avatar de aristide_b aristide_b - Invité de passage http://www.developpez.com
le 02/03/2015 à 20:50
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 ?
Avatar de Luc Hermitte Luc Hermitte - Expert Confirmé Sénior http://www.developpez.com
le 03/03/2015 à 11:36
Citation Envoyé par aristide_b Voir le message
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.
Avatar de Logan Mauzaize Logan Mauzaize - Rédacteur/Modérateur http://www.developpez.com
le 03/03/2015 à 13:11
Citation Envoyé par aristide_b Voir le message
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 ?

Citation Envoyé par aristide_b Voir le message
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.

Citation Envoyé par aristide_b Voir le message
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.
Avatar de koala01 koala01 - Modérateur http://www.developpez.com
le 04/03/2015 à 11:12
Citation Envoyé par Logan Mauzaize Voir le message
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
Avatar de Logan Mauzaize Logan Mauzaize - Rédacteur/Modérateur http://www.developpez.com
le 04/03/2015 à 11:38
Citation Envoyé par koala01 Voir le message
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.
Avatar de Mat.M Mat.M - Expert Confirmé Sénior http://www.developpez.com
le 04/03/2015 à 19:00
Citation Envoyé par el_slapper Voir le message
non, clairement, sur le style et la syntaxe. Chacun a sa préférence, mais il y a des gens pour qui l'un est insupportable, et l'autre absolument génial. Certains qui vont trouver l'un inqualifiable, et l'autre parfait. En fait, c'est juste une question d'habitude. Mais quand les habitudes sont bien ancrées, difficille de passer de [CODE]If Blabla Then
ok d'accord tu as raison mais la syntaxe d'un langage de programmation c'est pas ça qui fait la réussite d'un projet informatique, pas d'accord ?
La réussite d'un projet informatique c'est un projet qui tourne sans bugs et bien construit...
Avatar de el_slapper el_slapper - Expert Confirmé Sénior http://www.developpez.com
le 05/03/2015 à 10:40
Citation Envoyé par Mat.M Voir le message
ok d'accord tu as raison mais la syntaxe d'un langage de programmation c'est pas ça qui fait la réussite d'un projet informatique, pas d'accord ?
La réussite d'un projet informatique c'est un projet qui tourne sans bugs et bien construit...
Oui. Mais c'est une œuvre de l'esprit. Et pas qu'au sens légal. Les process cognitifs humains sont souvent ancrés profondément, et tu peux avoir un différentiel de productivité colossal pour des bêtises de ce genre. Quand quelqu'un qui a toujours fait, dans sa vie :
Code :
1
2
3
4
for (compteur = 0; compteur < 50; compteur++)
{
    Console.WriteLine("Bonjour C# " + compteur);
}
et qu'il doit faire
Code :
1
2
3
For compteur = 0 to 49 Step 1
    Console.WriteLine("Bonjour VB.NET " & compteur)
Next compteur
il sera déstabilisé, et moins productif, et fera plus d'erreurs. Si on va plus loin et qu'on essaye de lui infliger
Code :
1
2
3
4
PERFORM VARYING COMPTEUR FROM 0 BY 1 UNTIL COMPTEUR > 49
    MOVE COMPTEUR TO COMPTEUR-FORMAT-DISPLAY
    DISPLAY "Bonjour COBOL " COMPTEUR-FORMAT-DISPLAY
END-PERFORM
il va hurler, se débattre, crier à la torture, que COBOL c'est pas un langage civilisé, qu'écrire "1{" au lieu de "10" si on ne passe pas par une variable intermédiaire, c'est de la débilité, etc..... Et il ne va pas être productif. Alors que quand on le connait bien, COBOL est un langage très productif(dans sa niche, et seulement dans sa niche, dont il ne sort quasiment plus, et c'est une bonne chose). Mais l'informaticien diplômé, baigné de C#, de JAVA, voire de langages fonctionnels, va se révolter contre ce langage archaïque qui n'a rien de ses jouets modernes. C'est pour ça qu'on continue de former des non-informaticiens au COBOL, alors que pas mal de diplômés en informatique sont au chômage. Et que ça requiert pourtant les mêmes qualités.

En bref, pour revenir à ta question, les deux sont liés. Ce qui compte, c'est bien que le projet marche bien, sans bug, avec des performances acceptables, soit maintenable, etc... Mais la syntaxe a un effet important sur tout ça, en fonction des gens qu'on a a disposition. Certains sont plus malléables(j'arrive à m'en sortir avec l'objet, même si je n'aimerais jamais ça), mais passer d'un système à un autre identique, mais avec une syntaxe différente, ça n'a rien d'anodin.
Avatar de AbA2L AbA2L - Futur Membre du Club http://www.developpez.com
le 18/03/2015 à 1:29
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
Offres d'emploi IT
développeur php confirmé
CDD Freelance Mission
105635671273443701867 - Ile de France - Paris (75000)
Consultant Technico Fonctionnel SAP
CDI
Capgemini - France - Strasbourg (67000)
Webmaster/Administrateur de site (H/F)
CDI
NCC INSOLITE - Champagne Ardennes - NOGENT (52800)

Voir plus d'offres Voir la carte des offres IT
 
 
Partenaires

Hébergement Web