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