Discussion :

[ptah35]

Contrairement au c++, VB.NET et JAVA permettent de faire du développement internet.

Rien empêche de faire du développement Web ou internet, avec du C++ ou avec n'importe quel autre langage d'ailleurs...
Si votre application utilise la majeure partie des services de JavaEE ce n'est peut-être pas une bonne idée de se lancer dans un portage en C++, mais le développement Web est aussi utilisé pour réaliser des interfaces homme-machine pour des routeurs par exemple.

Oui c'est tout récent (Java 8).
Mouais enfin c'est un peu tiré par les cheveux quand même. Ces deux langages sont quand même très éloigné.
A la rigueur tu m'aurais dit C# qui a une approche assez similaire (même si là encore il y a également beaucoup de différence)

C# et VB.NET sont aussi différent l'un de l'autre qu'une panthère l'est d'un jaguar... Mêmes paradigmes, même bibliothèque de classes, même machine virtuelle...

[el_slapper]

(.../...)C# et VB.NET sont aussi différent l'un de l'autre qu'une panthère l'est d'un jaguar... Mêmes paradigmes, même bibliothèque de classes, même machine virtuelle...

oui et non

oui à 100% sur l'aspect technique. Ce sont des langages équivalents en termes de capacilité technique.

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
If Blabla Then
    Blibli
End If

à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
if(Blabla){
    Blibli
}

C'est une autre manière d'écrire, mais surtout de lire. Notre cerveau est branché cognitivement sur une manière spécifique de coder(moi sur la première, la plupart des gens qui ont fait des études d'info sur la seconde), et a beaucoup de mal à lire correctement l'autre.

Alors que, techniquement, tu as raison, c'est 100% équivalent.

[ptah35]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
If Blabla Then
    Blibli
End If

à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
if(Blabla){
    Blibli
}

Je me souviens que lorsque j'étais étudiant, je détestais PASCAL pour la même raison, je ne jurais que par le C . Mais après une vingtaine d'années à travailler avec différents langages non seulement impératifs, mais également fonctionnels, je ne me soucie plus de ce genre de détails... un bloc est un bloc qu'il s'écrive entre accolades ou entre un begin et un end ou même par la simple indentation...

[Ubiquité]

L'un est à typage dynamique l'autre statique, ça fait un grosse différence de paradigme.

[ptah35]

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#.

[aektiareti]

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++

[Sennad]

Java plus utilisé qu C++

C'est quoi cet argument bidon ? ...

[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.

[Mat.M]

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...

[el_slapper]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
for (compteur = 0; compteur < 50; compteur++)
{
    Console.WriteLine("Bonjour C# " + compteur);
}

et qu'il doit faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[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.

[teddy vondutch]

J'ai intitulé ' Un jugement influencé' du fait de la formatio acquise dans le milieu où je vis , en l’occurrence en RDCongo un pays souvent manquant dans la liste des pays de beaucoup de programmes et applications quand il s'agit de sélectionner un pays. A vrai dire la formation suivie relègue le C++ à un langage sans finalité quelconque, et dans certains parcours informatiques le C++ ne se limite qu'à la POO du C et en l'introduction de la bibliothèque canio, en revanche Java est un langage apprécié par les professeurs et enseignants ce qui fait à ce que dans mon environnement le C++ est un langage comparable à l'assembleur.
Heureusement, grace à l'outil internet, un luxe chez nous, j'ai pu apprendre par moi-meme que le C++ est un langage très utilisé dans le monde de la programmation, d'où l'idée de trouver un moyen non appris à la fac pour aboutir à des programmes non séquentiels et ne faisant pas que des opérations basiques. C'est là où je fis connaissance de Qt qui est pour moi une porte qui m'a permis à voir au delà de java.
En somme, le C++ est un langage peu vulgarisé chez nous que le java, mais il très puissant que ce dernier.

[JPRIVES]

J'ai développé dans beaucoup de langages ( C, C++, JAVA, COBOL, VB, Delphi, Windev ...) et je suis arrivé à une seule conclusion.
L'important c'est ce qui fonctionne avec un minimum de temps de programmation en permettant de faire gagner du temps aux personnes qui utilisent vos logiciels quel que soit le langage et la méthode programmation.

[liberal1]

C++ beaucoup plus rapide que java.

Les paramètres tableaux en Java sont plus optimizables sur que les pointeurs en C++.

Si une fonction prend en référence deux tableaux x et y (deux pointeurs sur les éléments en C ou en C++) :

en Java

deux références de tableaux comme paramètres d'une fonction sont soit
- deux références sur le même tableau
- deux références sur deux tableaux disjoints : tout élément d'un tableau ne peut pas être un élément de l'autre

Comme en géométrie euclidienne deux droites parallèles sont
- la même droite
- ou disjointes

Attention : les éléments différents peuvent recevoir des valeurs égales. Un tableau de références peut avoir tous les éléments contenant une référence égale; donc tous les éléments se référent à un même objet. Même changer la valeur d'un élément (la référence, pas le référant) n'affecte pas la valeur d'un autre.

Donc un compilateur peut insérer un test x!=y et ensuite supposer que les accès aux tableaux sont indépendants : une modification de x[i] ne peut pas affecter un accès à y[j] quels que soient les valeurs de i et j (il faut aussi gérer le cas x==y évidemment)

Sans le test x!=y, le compilateur sait que x[i] et y[i+1] ne se réfèrent pas au même élément.

en C++

Deux pointeurs à l'intérieurs de tableaux x,y peuvent
- être égaux : x==y

- être différents d'une certaine valeur d :
y-x == d et x+d == y

- être différents sans aucune relation entre eux (pointant dans deux tableaux disjoints)

Vérifier x!=y n'implique pas que les tableaux sont disjoints.

x[i] et y[i+1] peuvent se référer au même objet.

[liberal1]

- JAva ne permet pas l'héritage multiple, en revanche son système d'interfaces est très souple.

Les "interfaces" de Java sont des classes abstraites arbitrairement limitées.

C'est un système qui est tout sauf souple.