Bonjour,
 
J'aimerais faire un listing des différences qu'il existe entre le language C++ et le Java.
D'après mes connaissances je note (en vrac):
 
- la surcharge d'opérateurs (C++)
- les pointeurs (C++)
- les espaces de nommage (C++)
- l'héritage multiple (C++)
- code executé sur une machine virtuelle (Java)
- les interfaces (Java)
- friend (C++)
- les directives de compilation (C++)
- la notion de package (Java)
- possibilité d'écrire du code "séquentiel" c'est à dire en dehors d'une classe, comme en C (C++)
- le garbage collector (Java)
 
 
Si vous voyez d'autres choses pertinentes, elles sont les bienvenues.
 
J'ai mis le qualificatif friend dans la liste parce qu'un jour on m'a expliquer qu'il existait une faille, en tout cas un défaut, inhérent au langage Java parce qu'un développeur ne pouvait pas transmettre des classes et empêcher celui a qui il les transmet de faire certaine choses. C'est pas très bien expliqué parce que je me souviens plus justement de l'explication. Toujours est-il que la solution a ce problème existe en C++ avec le qualificatif friend justement.
Donc ma deuxième question est la suivante: quelle est donc cette "faille" du langage Java dont mon interlocuteur parlait (un développeur Java confirmé).
 
Merci pour vos contributions.

J'préfère laisser la parole à un spécialiste, Bruce Eckel par exemple : http://www.javacoffeebreak.com/art [...] djava.html

oui effectivement c'est très détaillé comme différences, merci.
 
En ce qui concerne la "faille" dans Java, personne ?

Essaye de la retrouver, mais le dernier qui m'explicait cela, c'etait pour faire des cochonneries, a savoir n'autoriser que certaines classes a utiliser certains champs. Hors, cela signifie deux choses.
 
- Il est facho et veux que la classe connaisse de maniere exclusive ses utilisateurs, ca va contre toutes regles  de reutilisabilité, de separation of concern et de morale programmatic. Donc, c'est mal.
 
- Une partie d'une classe est fortement correlee a une partie d'une autre classe. A doit manipuler des trucs de B pour une realisation  precise, mais personne d'autre. Mais cela cache en fait une notion qui fait que A et B sont indisciable dans leurt utilisation et font partie d'un meme composant complexe. Dans ce cas, ces classes sont dans le meme package, et les trucs qu'elles se tripotent ont la visibilité package (qui n';existe pas en c++).
 
 
 

Je sais pas mais son explication était très cohérente et la manière dont il expliquait ça faisait penser qu'il  s'agissait d'un problème bien connu. Ce programmeur à vraiment un gros niveau en Java donc je pense que y'a vraiment quelque chose de valable derrière.
Si quelqu'un (un programmeur C++ par exemple) a une idée...

Je suis capable d'expliquer d'enorme connerie avec applomb et coherence j'suis consultant

Je connais une technique mais bon, ce n'est pas vraiment une faille, c'est la suivante :
Pour accéder à un champ ou une methode privée, avec reflexion, on peut récupérer la liste de tous les champs ou méthodes (y compris les privés) avec Class.getDeclaredFields ou Class.getDeclaredMethods.
Ensuite sur les champs ou les méthodes (private) qui nous intéressent, on appelle setAccessible(true) puis on peut récupérer la valeur du champ ou appeler la méthode et ça passe !
Il y a des chances que c'est de cela dont tu veux parler, mais ce n'est pas une faille du tout car on peut empêcher ce genre de code en utilisant un SecurityManager qui permet de déclencher une exception si on utilise setAccessible sur un membre privé ... donc au final ce n'est pas un faille mais juste un truc à connaître !
 
Ciao

Les const en C++ qui n' existent pas en java.

 
Cf. le lien que j'ai posté ci-dessus :

Un des gros + de java sur le c++, c'est l'API reflexion ainsi que les annotations depuis 1.5 ... et c'est vraiment un gros plus ...
Par contre les référence constantes sont un gros manque de java par rapport au c++ même s'il existe les final, mais bon le final est moins 'efficace' que la référence constante...

Bon article mais malheureusement vieux ...
En particulier les ajouts de Java 1.5 :
- Génériques (équivalent aux templates C++)
- Annotations
- Boucles for style foreach php
- Auto boxing/unboxing (pas d'équivalent C++ les Wrappers de types primitifs n'existent pas et ne serviraient à rien ...)
- Énumérations (orientées objets ...)
- Arguments variables (comme en C/C++)
- Typedef inexistant en java (relou quand on doit tapper Map.Entry<Integer, String> dans toutes ses méthodes ... )
Et puis sinon, à part les différences de langage, il y a aussi les différences dues à l'architecture (bytecode, jvm) :
- Meilleure sécurité d'exécution car isolation + vérification du code dans la jvm
- Avec Reflection possibilité de 'découvrir' des classe inconnues (méthodes, membres ...)
- Perfs et optimisations moins bonnes que le C++
- Chargement dynamique (au runtime) de code avec le ClassLoader
 
En tous cas le C++ garde garde toujours son meilleur avantage : étant plus proche de la machine, il est toujours plus efficace
Et puis pas besoin d'installer une jre de 15Mo (85Mo une fois installé) pour exécuter un simple Hello World

Sûrement pas.

C++ a des macros boost globalement équivalentes dans les cas simples.
(je note également que PHP n'a sûrement pas inventé les foreach)

On peut pas dire qu'il soit terrible

C'est bizarre, je croyais que les templates C++ servent à paramétrer un type d'une classe ou d'une méthode et que les générique java servent ... à faire la même chose (mise à part quelques petites différences techniques ...) !
Au passage j'ai employé le terme 'équivalent' et pas 'identique' ...

Effectivement boost apporte un truc équivalent, mais boost n'est qu'une librairie pour le C++, ça ne fait pas partie du langage (même si un partie des librairies boost va être ajoutée au futur C++0x, je sais ...), alors que dans le cas de Java 5, c'est carément un élément du langage.
Et merci pour la leçon, je sais que PHP n'a pas inventé le foreach, je citais le php car c'est un langage commun et assez connu de pas mal de gens ... (la preuve, le premier site renvoyé par google quand on tape foreach, c'est php manual !)
Concernant la remarque sur l'auto-boxing, j'en vois vraiment pas l'intérêt ...
 
C'est bizarre je croyais que l'idée de ce topic était de lister les différences entre C++ et Java ... merci de ta contribution pour faire avancer le débat ...

C'est pas plus équivalent qu'identique, les templates C++ sont beaucoup plus puissantes que les generics (et beaucoup plus compliquées), les generics java ne sont sûrement pas turing-complete, les templates si.

Pour toute personne saine d'esprit (sauf à la limite à être dans l'embedded) Boost va de pair avec le C++.

C'est à dire ?

Et alors ?

Si je comprends bien, à part me ressortir toujours les mêmes pseudo arguments, ça ne réponds pas à ma question...
En quoi ce n'est "Surement pas" un équivalent ? vu qu'à part quelques détails de masturbation intellectuelle, ça fait la même chose, c'est à dire à faire du polymorphisme paramétré (et non polymorphisme dynamique, je m'étais trompé de terme dans mon précédent post ...)

Je travaille dans une boite d'info qui fait entre autres des projets en C++, et c'est tout sauf une évidence que d'utiliser Boost quand on fait du C++, tout dépend du besoin qu'on à ...
 
PS: tu as le droit de parler français surtout quand les termes existent ... (embedded -> embarqué, turing-complete -> turing complet) après si tu veux te donner un style ...  
 
PS: je ne cherche pas à dire qu'un des langages est mieux que l'autre, c'est juste un listing des différence et éventuellement des analogies entre les deux ... ceci n'est pas une guerre de religion ... c'est pas la peine de s'énerver ...

Les Generics de JAVA font tout sauf faire de la vrai généricité vu qu'il retombe dans du Object pour résoudre le type effectif.
Les templates C++ sont un sous-langage fonctionnel pure de calcul de type, rien à voir donc.

Quand à boost, vu que c'est l'antichambre de la STL, ne pas l'utiliser est aussi risible (modulo pb de plateformes exotiques) que de pas utilise la STL.

PS : embedded != embarqué

Oui enfin, là on parle d'implémentation ... quand je dis que ce sont des équivalents, c'est au niveau de la conception et de la programmation (pour le développeur qui ne se soucie pas de toutes les détails et des impacts perfs), c'est dans ce sens que ce sont des équivalents car encore une fois ils ont la même vocation à la base (faire du polymorphisme paramétré) ...
Personnellement je trouve que dire le contraire est de mauvaise foi... ok ya des différence, mais de là à dire que ça n'a rien à voir, je trouve ça abusé.
Quant à Boost, encore une fois tout dépends du contexte, si tu fais de l'informatique de gestion (càd pas très technique) et que tu n'en a pas besoin alors c'est normal de ne pas l'utiliser ...
Et par contre ça m'intéresse de connaître la différence entre embedded et embarqué ...
Cf wikipédia :
"Un système embarqué peut être défini comme un système électronique et informatique autonome, qui est dédié à une tâche bien précise."
"An embedded system is a special-purpose computer system designed to perform one or a few dedicated functions".
 
Bon sinon, si je me suis acharné, c'est surtout à cause de ton employé par Masklinn, surtout quand tu lis le titre du topic ...
J'avais envie de titiller un peu quoi. Et puis est-ce qu'on peut m'en vouloir de troller un petit peu ?
 
(Désolé pour avoir pourri ton topic cimourdain )

le troll c'est vendredi, fallait patienter

Le Java c'est nul, y a pas de pointeurs.

Sorry, mais t'as dû passer à côté de quelque chose.
 

Il a aussi le droit de choisir les termes en anglais, langue usuelle en informatique.
 
Et pour ton édification, sache que culturellement, les termes techniques anglais sont très utilisés ailleurs qu'en France (p.e. à Bruxelles, environnement international et multilingue oblige), et qu'on peut également les considérer comme parfois moins ambigus que leurs traductions française.
 

Va troller ailleurs sur le topic élection  

 
mais si, pourquoi tu crois qu'il existe une NullPointerException

Parce qu'il n'y a pas de pointeurs?

Je veux bien admettre que j'ai tort, sauf que je ne comprend pas pourquoi ?
Est-ce que std::list<std::string> et ArrayList<String> ne sont pas censé illustrer ce que je dis depuis le début ?
Que les Java Generics comme les C++ templates ont à la base la même vocation qui est de pouvoir paramétrer une classe ou une méthode pour pouvoir rendre le code générique ?
En tous cas si ce que je dis est faux j'aimerais savoir pourquoi.
Je suis d'accord pour dire qu'il ya des différences :
- en java les types passés en génériques sont interprétés comme Object par défaut alors qu'en C++ il n'y a pas d'interprêtation à priori
- en C++ le code est généré à la compil pour chaque type paramétré alors qu'en Java il est généré une seule fois (en le considérant comme Object ou une classe dérivant d'Object)
Mais ça ne contredit pas ce que je dis au début.

Je sais mais comme je l'ai dit plus haut, c'était surtout pour troller et parce que je n'avais pas aimé le ton de ses messages (un peu trop pédant à mon goût...)

C'était pas de la pédanterie de sa part, c'est de la pelle à clouterie

C'est de bonne guerre ...

Je suppose que c'est ça, la faille dont il parlait.