Discussion :

[manueld]

Ah je vais me faire taper sur les doigts par les développeurs C++! Ou pas.

Car je me dis pour moi, qui fait la "free java", pas la java sans joie, mais la programmation libre d'applications Java

pourquoi pas passer en C++?
Quels sont les avantages ou inconvénients?
Par plateforme? (Android, Apple, Windows, Linux, etc)
Quels sont les outils libres ou non pour convertir le code? faut-il tuti réécrire à la main?
Comment se constituer sa propre bilbo-thèque de bibliothèques? (Java base => peut-être plusieurs bibliothèque; Maven => Où trouver des bibliothèques C++, quels sont les systèmes de build*)?

[Bousk]

pourquoi pas passer en C++?

Pourquoi une telle question ?
Tu te plais en JAVA et ne vois pas d'intérêt à passer au C++ ? Alors pourquoi ne pas rester en JAVA ?

Quels sont les avantages ou inconvénients?

Tu m'excuseras mais je n'ai pas grand envie de faire un résumé ici des 500 M de sujets qui parlent de ça, à commencer par ce forum, le forum débat, et dans tout l'interweb.

Quels sont les outils libres ou non pour convertir le code? faut-il tuti réécrire à la main?

N'ayant jamais eu ce besoin je ne m'y suis pas intéressé. Ca me parait pas impossible, mais le résultat sera surement très moche pour rester poli.

Comment se constituer sa propre bilbo-thèque de bibliothèques? (Java base => peut-être plusieurs bibliothèque; Maven => Où trouver des bibliothèques C++, quels sont les systèmes de build*)?

www.google.com

[ternel]

Pour les bibliothèques techniques, il y a deux sources majeures: la STL (entre autre <algorithm>) puis boost

Pour les bibliothèques métier (serveur web, 2D, 3D, etc) c'est à voir à chaque sujet.

[koala01]

Salut,

Déjà, il ne s'agit pas de "rétrograder" d'un langage vers un autre : Les possibilités de java et de C++ sont suffisamment semblables pour qu'ils soient considérés à égalité

Cependant, il faut avouer que java est plus "idiot proof", de par sa philosophie (et l'utilisation de la machine virtuelle, dont le garbage collector) que C++, qui est un langage dans lequel les erreurs de conception se payent "comptant"

Je ne veux pas dire par là que les développeurs java sont tous incompétents, mais bien que, comme java fait que certaines questions ne se posent de toutes façons pas, un développeur java passant au C++ risque fort de ne pas avoir le "réflexe" de se poser des questions primordiales car, il faut l'avouer : on ne développe absolument pas de la même manière en java qu'en C++

Pour ce qui est des avantages et des inconvénients, il faut se rendre compte que ce que l'un peut considérer comme un avantage sera sans doute considéré par l'autre comme un inconvénient. Par exemple, C++ apporte beaucoup plus de liberté que java car la mentalité de C++ vis à vis d'une fonctionnalité potentiellement dangereuse (si mal utilisée) est toujours de donner la possibilité d'y recourir, alors que celle de java est d'empêcher de le faire, quitte à mettre des "work arounds sécurisés" qui reviendront au même.

Je considère, personnellement, que c'est un avantage, car je n'aime pas être "limité" dans mes choix conceptuels par le langage. Mais cette liberté vient avec celle de se tirer une balle dans le pied si les décisions conceptuelles sont mauvaises. Et ca, ca peut être considéré par d'aucuns comme étant un inconvénient.

Autrement, il y a l'avantage des langages compilés Vs les langages utilisant une machine virtuelle, mais, à l'heure actuelle, cette différence s'avère relativement minime.

De manière générale, la conversion d'un langage à un autre peut parfaitement être automatisée (c'est d'ailleurs ce que fait n'importe quel compilateur / interpréteur au final ) mais le code ("java" ou "C++") n'a sans doute rien de commun avec ce que tu aurais fait à la main (sans pour autant être "moins efficace", ceci dit ).

La bibliothèque standard (SL / STL) de C++ est relativement limitée, mais il y a la bibliothèque boost qui préfigure d'une certaine manière de nombreuses évolutions futures à ce niveau là. Et si tu as besoin d'une IHM ou autres composants graphiques, Qt s'avère être un choix judicieux (bien qu'elle souffre du poids de son histoire, débutée bien avant qu'il n'y ait une normalisation correcte de C++)

Tout ceci étant dit, si tu te pose la question de savoir si tu dois passer au C++, surtout si, dans ton esprit, il s'agit de "rétrograder" de java à C++, mon impression est -- très honnêtement -- que tu n'as absolument aucune raison de faire la transition.

lorsque tu auras changé ton point de vue et que tu envisageras la liberté conceptuelle et la gestion fine des ressources comme des avantages au lieu de considérer le risque de fuites mémoire (qui ne devraient d'ailleurs plus arriver en C++ modernes) ou celui de risquer de se tirer une balle dans le pied comme des inconvénients, et que tu en viendras donc à considérer que tu va gagner énormément à utiliser C++ au lieu de java (alors que pour l'instant, tu semble persuadé que tu va perdre énormément), alors, oui, il deviendra peut-être intéressant d'envisager la transition.

Mais tant que tu es dans cet état d'esprit de "risquer de perdre" tes acquis java, il vaut mieux que tu t'en tiennes au langage que tu aimes et maîtrise

[bretus]

De manière générale, la conversion d'un langage à un autre peut parfaitement être automatisée (c'est d'ailleurs ce que fait n'importe quel compilateur / interpréteur au final ) mais le code ("java" ou "C++") n'a sans doute rien de commun avec ce que tu aurais fait à la main (sans pour autant être "moins efficace", ceci dit ).

Je te trouve optimiste là dessus... Un tel générateur "Java" vers "C++" devrait enrichir le runtime du C++ au point que dépendre de la JVM serait moins grave.

[RedSkidy]

je vais surement me faire insulter par tous les pros-java mais essaye de jouer a minecraft sur un pc moyen et regarde tes fps par rapport a ce qu'est le jeu. voilà pourquoi.

[imperio]

je vais surement me faire insulter par tous les pros-java mais essaye de jouer a minecraft sur un pc moyen et regarde tes fps par rapport a ce qu'est le jeu. voilà pourquoi.

Là par-contre tu t'aventures sur le mauvais terrain. Les performances de minecraft (ou fps, comme tu veux) sont dues à sa façon d'afficher le monde (en voxel donc). Il faut tester chaque bloc pour savoir s'il est affichable ou non en vérifiant son exposition. De plus, les performances de java sont désormais très proches de celles du C++. Un autre exemple, plus concret et moins subjectif serait le bienvenue.

[koala01]

Je te trouve optimiste là dessus... Un tel générateur "Java" vers "C++" devrait enrichir le runtime du C++ au point que dépendre de la JVM serait moins grave.

Pas forcément... Il serait tout à fait possible de produire du code C++ au départ d'un code java (et inversement) automatiquement, à partir du moment où l'on a pu générer un AST du code d'origine. Après tout, c'est ce que font tous les compilateurs, et c'est le principe sur lesquels reposent les framework multi-langages comme .net

Il y aurait sans doute quelques incompatibilités dans certains sens (ex : le delete qui est absent de java), mais, de manière générale, une fois que le code est correctement parsé, tu peux -- de par la nature "reproductible" et "prédictible" même des langages de programmation -- traduire n'importe quel langage en n'importe quel autre, ou peu s'en faut.

Je ne parle bien sur ici que de la "génération du code", car il faudrait par la suite compiler effectivement le code généré pour obtenir l'exécutable / la bibliothèque

[Christophe]

Pour moi, la grande différences entre java et C++ c'est que java fonctionne n'importe où même sur les téléphones à partir du moment ou il y a une machine virtuelle, c'est de l'interprété. C++ doit être compilé pour chaque plateforme.

Autre point : l'interface graphique. Sur Java si je ne me trompe on utilise swing (du moins en natif), il te faudra transcoder vers l'interface graphique de destination.

Donc c'est un gros boulot, et faut que ça en vaille la chandelle.

[smarlytomtom]

bonjour !
Ma réponse à moi sera très simple ! Je penses que le java et le C++ ne sont pas destiné aux même besoins !
Si tu veux faire une applications vraiment lourde tu aura meilleur temps d'utiliser le C++ car en tant que langage entièrement compilé, tu gagnes en rapidité. Par contre si tu veux faire une application plus petite mais avec une portabilité à toutes épreuves, choisis le java.
Attention je ne dis pas que l'on ne peux pas faire de gros programmes en Java et que le C++ n'est pas du tout portable loin de la !

Pour ce qui est de la conversion de code oublies ! Dans de nombreux cas on ne penses pas de la même façon son code en Java et en C++ !
J'espère que ma contribution t'aura aidé à voir plus clair !

[bretus]

Pas forcément... Il serait tout à fait possible de produire du code C++ au départ d'un code java (et inversement) automatiquement, à partir du moment où l'on a pu générer un AST du code d'origine. Après tout, c'est ce que font tous les compilateurs, et c'est le principe sur lesquels reposent les framework multi-langages comme .net

Les compilateurs passent tous d'une AST à un code "à plat" non? C++ => code machine, Java => bytecode, DotNet => MSIL (~bytecode).

Dès lors, même passer du bytecode à du code machine nécessite de se reposer sur une couche de runtime : JVM/CLR.

[RedSkidy]

Là par-contre tu t'aventures sur le mauvais terrain. Les performances de minecraft (ou fps, comme tu veux) sont dues à sa façon d'afficher le monde (en voxel donc). Il faut tester chaque bloc pour savoir s'il est affichable ou non en vérifiant son exposition. De plus, les performances de java sont désormais très proches de celles du C++. Un autre exemple, plus concret et moins subjectif serait le bienvenue.

y'a aussi le fait qu'ils utilisent plein d'objets temporaires (comme un objet pos par exemple qui contient des coordonnées x y et z qu'ils utilisent pour passer des coordonnées a une fonction au lieu des coordonnées directement) et je m'y connais pas trop en java mais je crois que c'est le garbage collector qui s'occupe de supprimer tout ça et ça fait des freeze

[koala01]

Les compilateurs passent tous d'une AST à un code "à plat" non? C++ => code machine, Java => bytecode, DotNet => MSIL (~bytecode).

Dès lors, même passer du bytecode à du code machine nécessite de se reposer sur une couche de runtime : JVM/CLR.

Les compilateurs ne font que respecter des règles particulières pour traduire les codes qu'ils ont parsé dans un langage dans un langage différent.

La meilleure preuve en est que pour toute la collection Gcc, il n'y a qu'un seul backend (une seule partie responsable de la génération du code assembleur / binaire), mais que la différence se fait au niveau du "frontend", pour prendre les différents langages en compte.

Autrement dit, le frontend va générer un AST "commun" à tous les langages au départ de codes écrits dans différents langages. Il est vrai que l'étape "logique" suivante est donc de générer du code assembleur, indépendamment du langage d'origine, mais pourquoi devrais tu forcément passer à quelque chose de "plus bas niveau" (bytecode, assembleur, ...)

Après tout, cette nécessité n'apparait que dans la logique dans laquelle on se trouve d'obtenir quelque chose d'utilisable par le processeur au final. Mais, si tu changes ta logique, tu peux décider de changer les règles de génération pour obtenir absolument tout ce que tu veux, y compris, du code (texte, adapté au lecteur) dans n'importe quel langage de ton choix

D'ailleurs, si ma mémoire est bonne, le premier compilateur C++ n'était "rien d'autre" qu'un "précomilateur" qui traduisait le code C++ en C, avant que le compilateur C ne prenne le relais pour générer le code binaire final.

Il ne faut pas oublier que, quel que soit le langage que l'on utilise pour notre projet, il ne s'agit que de conventions destinées à permettre "une application" de vérifier ce que l'on a écrit avant de le "traduire" dans un ensemble de conventions différentes et que la différence principale qu'il peut y avoir entre deux langages se trouve au niveau des conventions utilisés. Une fois que l'AST correspondant à ton code a été généré (que le "front end" a fait son job), tu as finalement toute liberté quant au format de sortie (quant à la manière dont le "back end" va travailler). Tu créerais des règles pour traduire ton AST en chinoix ou en polonais "primaire" (comprends : sans forcément disposer de toutes les nuances de la langue), cela reviendrait encore au même

[JolyLoic]

Ce n'est pas au niveau de l'AST que le code est commun, mais après, au niveau du code intermédiaire, qui est une sorte de mini assembleur. L'AST a justement pour but de prendre en compte toutes les spécificités du langage, et même si on retrouve des nœuds semblables, les AST sont assez différents.

Après, au delà de la syntaxe, les langages ont aussi des modèles objet différents. Par exemple, en C++, un objet peut en contenir directement un autre, alors qu'en Java, il ne peut contenir que des pointeurs. Ça se traduit au final par un code plus simple à écrire en Java (pas de question à se poser sur le mode d'aggrégation) mais moins performant (moins de localité de la mémoire pour le cache, plus de mémoire utilisée). Ou encore le fait que Java utilise un seul type de polymorphisme pour le polymorphisme souvent resolvable au compile-time et celui résolvable uniquement au run-time (avec des algos qui essayent quand même de résoudre au compile-time, mais sans garantie), là où le C++ utilise deux mécanismes différents (fonctions virtuelles et templates) mais avec une garanti que le second est résolu à la compilation (au prix d'une écriture plus lourde, et de temps de compilation allongés, donc d'une baisse de productivité du développeur).

Je vais donner un exemple que j'aime bien, par rapport au langage C# (qui est très proche de Java en tant que système objet) : Les développeurs de Microsoft ont porté récemment leur compilateur C# depuis le C++ vers du C#. On peut difficilement soupçonner de telles personnes de parti-pris anti C#. Et un membre de cette équipe a déclaré qu'au début du projet, ils avaient des contraintes de performance très strictes, qu'ils ne savaient pas du tout s'ils seraient capable d'y parvenir. Ce cahier des charge était le suivant : Ne pas être plus de deux fois plus lent que le code existant en C++.

En résumé grossier, entre Java et C++, si ce que tu cherches à optimiser, c'est le coût de développement, utilise Java, si c'est les performances du résultat obtenu, utilise C++. Et si tu n'as pas de contraintes trop strictes, utilise ce que tu connais le mieux.

[JolyLoic]

Pour moi, la grande différences entre java et C++ c'est que java fonctionne n'importe où même sur les téléphones à partir du moment ou il y a une machine virtuelle, c'est de l'interprété. C++ doit être compilé pour chaque plateforme.

La portabilité ne se limite pas au code lui-même, mais à un tas d'autres dépendances à l'environnement. Un code (Java, C++, peu importe) développé sur une seule plate-forme ne tournera pas bien sur une autre, il y aura toujours un effort de portage à faire (par exemple, windows/linux : L'un des OS est case-insensitive, l'autre pas). En C++, cet effort comprends une phase de recompilation qui n'est pas là en Java, mais je pense que c'est annexe.

Et autre point, tous les téléphones ne supportent pas Java. Tous supportent le C++...

Autre point : l'interface graphique. Sur Java si je ne me trompe on utilise swing (du moins en natif), il te faudra transcoder vers l'interface graphique de destination.

Tu donnes là un autre exemple... L'interface graphique utilisée sur Android par exemple n'a rien à voir avec swing, donc la portabilité PC => android demandera encore plus d'effort.

[Christophe]

Et autre point, tous les téléphones ne supportent pas Java. Tous supportent le C++...

Tu as raison, j'ai donné les téléphones comme exemple.

Citation Wikipedia :

Le langage Java a débuté dans les années 1990 avec James Gosling qui souhaitait développer un langage de programmation indépendant de la plate-forme hardware. Oak (traduction : « Chêne ») fut un échec.
Logo de Java représentant une tasse de café.

Par la suite, Bill Joy (cofondateur de la firme Sun Microsystems) proposa une nouvelle version de Oak appelée « Java ». Son but était de pallier une déficience des langages de programmation en produisant un langage conçu pour des machines et des logiciels hétérogènes.

C'est nettement moins le cas maintenant notamment avec les évolutions de C/C++, PHP. Ca n'en rend pas nécessairement Java has-been

Tu donnes là un autre exemple... L'interface graphique utilisée sur Android par exemple n'a rien à voir avec swing, donc la portabilité PC => android demandera encore plus d'effort.

oui, c'est ce que je voulais dire. Il faudra utiliser un framework tel que GTK ou Qt (qt est utilisable avec Java avec Qt-Jambi - il doit certainement exister un moyen de le faire avec GTK) ou utiliser les API systèmes.

Après utiliser C ou Java pour un projet est à mon avis un choix de contexte, de compétence, de besoin, etc et dans l'absolu je ne peux pas dire que l'un est meilleur que l'autre (et je n'ai de toute façon pas les compétences nécessaires pour cela) ... mais pour recoder un projet Jave en C il faut à mon avis une raison valable.

[RedSkidy]

enfaite la question de base n'était pas "quel est le meilleur langage" mais plutôt quelles différences
déjà il n'y a pas de langage meilleur que l'autre ça dépend de ce que tu veut faire.
le C++ est plus performant, tu n'est pas obligé de faire de l'objet avec, il y a les templates... mais il est très compliqué il y a plus de chance de faire des erreurs qu'en java, plus de bugs... il faut aussi recompiler ton code entre 2 plateformes.
le c++ est puissant mais il faut savoir maîtriser cette puissance : si on te donne une pelleteuse tu pourra creuser plus vite qu'avec une pelle, mais si tu ne sait pas t'en servir, tu va surement casser quelque chose (dat epic métaphore).