Discussion :

[bricecol]

Je vois beaucoup de personnes qui évaluent l'espace mémoire que prend tel ou tel type de donnée en C++ ou en JAVA.

J'aimerais dire d'abord qu'avec un bon code JAVA, le temps de calcul ou l'espace supplémentaire en mémoire est aujourd'hui je pense négligeable. Évidemment, si je m'amuse à utiliser un "Integer" au lieu d'un "int" en JAVA alors que cela m'est inutile, j'admets être stupide et mon code sera légèrement plus lent.

Mais je pense à autre chose quand on me parle de ces deux langages que j'aime beaucoup. Il faut reconnaître que les concepteurs de JAVA sont partis sur la base du C/C++ en prenant soin je pense de ne garder que le meilleur tout en passant au maximum en notion objet (ils ont aussi créé les patterns les plus utilisés de nos jours). Certains diront que c'est trop objet, cependant c'est plus un avantage à mon avis. Même si j'adore le C++, il n'est pas contestable que n'importe qui sur du C++ peut écrire un code extrêmement "moche" si vous me permettez l'expression. Tout simplement parcequ'il est possible en C++ d'intervertir avec de l'écriture C. Et le mélange du C et du C++ (objet), donne selon moi un résultat 100 fois plus contestable que du JAVA, propre et net même si un peu plus lent.

Mon opinion est que le JAVA reste le langage le plus abouti et le plus propre à la fois, disposant de l'aboutissement de réflexions sur les problèmes parents au C/C++.

[jabbounet]

Je vois beaucoup de personnes qui évaluent l'espace mémoire que prend tel ou tel type de donnée en C++ ou en JAVA.

J'aimerais dire d'abord qu'avec un bon code JAVA, le temps de calcul ou l'espace supplémentaire en mémoire est aujourd'hui je pense négligeable. Évidemment, si je m'amuse à utiliser un "Integer" au lieu d'un "int" en JAVA alors que cela m'est inutile, j'admets être stupide et mon code sera légèrement plus lent.

Mais je pense à autre chose quand on me parle de ces deux langages que j'aime beaucoup. Il faut reconnaître que les concepteurs de JAVA sont partis sur la base du C/C++ en prenant soin je pense de ne garder que le meilleur tout en passant au maximum en notion objet (ils ont aussi créé les patterns les plus utilisés de nos jours). Certains diront que c'est trop objet, cependant c'est plus un avantage à mon avis. Même si j'adore le C++, il n'est pas contestable que n'importe qui sur du C++ peut écrire un code extrêmement "moche" si vous me permettez l'expression. Tout simplement parcequ'il est possible en C++ d'intervertir avec de l'écriture C. Et le mélange du C et du C++ (objet), donne selon moi un résultat 100 fois plus contestable que du JAVA, propre et net même si un peu plus lent.

Mon opinion est que le JAVA reste le langage le plus abouti et le plus propre à la fois, disposant de l'aboutissement de réflexions sur les problèmes parents au C/C++.

la propreté d'un code dépend uniquement du codeur, jai vu du code super lisible et illisible dans a peu près tous les langage que j'ai pratiqué et il yen a un paquet.

Savoir présenter un code est selon moi totalement indépendant du langage. d'ailleurs il y'a un topic sur le sujet (qu'est ce qu'un code propre ou quelque chose comme ça).

[_skip]

Justement à ce sujet, je suis tombé sur le langage D, successeur du C++ enfin si on l'admet comme tel ce qui me semble pas encore être le cas.
http://www.digitalmars.com/d/2.0/overview.html

C'est dommage que personne ne pousse ce langage car il semble extrêmement intéressant. La puissance du c++ avec plus de sécurité.

[Luc Hermitte]

a- Il faut reconnaître que les concepteurs de JAVA [...] (ils ont aussi créé les patterns les plus utilisés de nos jours).

b- Certains diront que c'est trop objet, cependant c'est plus un avantage à mon avis.

c- Mon opinion est que le JAVA reste le langage le plus abouti et le plus propre à la fois, disposant de l'aboutissement de réflexions sur les problèmes parents au C/C++.

a- Il n'y a pas une seule ligne de Java dans le GoF95. Juste du C++ et du SmallTalk. Depuis Gamma s'est pas mal investi dans Eclipse si mes souvenirs sont bons.

b- Une fois de plus, on ne peut pas comparer qualitativement ces deux langages sur cet axe là. Java est bridé OO, mais sans en supporter tous les aspects. Eiffel, c'est autre chose (je ne connais pas Smalltalk ou Ruby). Si c'était la qualité OO d'un langage qui devait nous dicter quoi utiliser, nous devrions tous faire de l'Eiffel, du Smalltalk, ... Et aucun de Java/C++/C#.
Mais toujours comme d'habitude, le multi-paradigme apporte une grande richesse au delà de la complexité supplémentaire introduite.
(cela me rappelle un truc que j'ai lu dernièrement : des gens qui disaient que la STL (avec son découplage générique algo vs conteneurs ; cf le cours d'algorithmique de Stepanov pour bien voir jusqu'où il pousse le bouchon) n'aurait jamais pu être faite dans un langage autre que le C++ -- ce qui éveille ma curiosité relativement au troll Pascal/Ada vs fonctionnel pour débuter dans un fil voisin ; mais ici n'est pas le lieu pour cela)

c- Je reconnais volontiers un gros plus à l'univers Java (qui comprend JVM et bibliothèque standard). Mais alors pas au langage qui est bien trop atrophié à mon gout. (je sais, nous ne sommes pas encore vendredi...)
Au delà des apports du MI pour le support natif de la PpC, ou des sucres de la surcharge des opérateurs pour les applications scientifiques, je vois aussi des grosses régressions comme avec le type racine void*^X^WObject qui introduit un micmac pas possible pour définir isequal() que l'on n'a pas en C++ ou en Ada vu qu'ils auront un typage plus précis.
Bref ce n'est pas ce que j'appelle une capitalisation réussie de l'expérience C++.
Est-ce que D, Fortress (ou la surcharge des opérateurs qui est aussi un truc utile, selon Sun) ou ruby, ou ..., font mieux ? Je ne sais pas, je ne les ai pas assez creusés.

[kpouer]

mais il faut trouver celui qui est motivé et capable de le faire

Je m'attendais à cet argument, mais il ne fait que mettre en avant le fait qu'il reste encore sans doute beaucoup trop de gens qui se foutent pas mal de la compatibilité, et qu'il y a donc encore un gros effort de sensibilisation à faire de ce point de vue...

Le tout, en prenant en compte le fait que certaines partie de code peuvent encore dater d'une époque où la compatibilité n'apparaissait absolument pas dans la liste des priorités et que le fait de repasser dessus demande de la motivation et du savoir faire

Mais c'est aussi un problème qui apparait de manière récurrente avec les langages plus "anciens" (et ayant donc une optique différente) que n'importe quel langage "suffisemment récent" pour avoir été envisagé dans une optique de compatibilité

Ba ca reste un fait malgré tout, il est bien plus simple de faire un logiciel multiplateforme en java qu'en C++, et ce n'est pas uniquement une question d'oublis ou de mauvaise volonté.
Je prend 2 exemples, Google Chrome et Amarok, tous les 2 sont annoncés sous Windows depuis belle lurette, et rien ne vient, comme quoi ca doit pas être si simple.
Ou encore certaines fonctionnalités de VLC (je crois l'upnp server) ne fonctionnent que sous linux.
De plus c'est vrai qu'il faut porter la JVM sur les différents OS, mais en C++ il faut porter le compilateur, donc le problème est similaire (même si une JVM est surement plus de boulot qu'un compilateur je te l'accorde).
Il y a une autre chose ou java a un avantage dans ce domaine c'est la compilation unique.
Si je fais un soft que je veux multiplateforme en java, je le compile une fois, j'ai pas besoin d'avoir un BSD, un Mac, et un exemplaire de chaque OS sur lequel je veux qu'il tourne

[kpouer]

mon post était hors sujet

[jabbounet]

De plus c'est vrai qu'il faut porter la JVM sur les différents OS, mais en C++ il faut porter le compilateur, donc le problème est similaire (même si une JVM est surement plus de boulot qu'un compilateur je te l'accorde).

les compilateurs croisé ça existe, dans ce cas tu n'as pas besoin de porter tout le code du compilateur et l'effort est réduit.

[kpouer]

les compilateurs croisé ça existe, dans ce cas tu n'as pas besoin de porter tout le code du compilateur et l'effort est réduit.

Oui c'est même courant, les SDK de téléphones portables par exemple, mais bon, si tu fais une appli de bureau, j'ai jamais vu un compilateur croisé permettant sur un même OS de compiler mon appli pour la faire tourner sous Windows, Linux, Mac et autres ...

[jabbounet]

Oui c'est même courant, les SDK de téléphones portables par exemple, mais bon, si tu fais une appli de bureau, j'ai jamais vu un compilateur croisé permettant sur un même OS de compiler mon appli pour la faire tourner sous Windows, Linux, Mac et autres ...

La c'est plus d'api du système que de compilateur à proprement parlé.

Porter une appli d'un unix vers un autre (même si l'archi du proc change) est beaucoups plus simple que de porter d'un unix vers windows.

au passage gcc peu etre croisé.

[koala01]

Oui c'est même courant, les SDK de téléphones portables par exemple, mais bon, si tu fais une appli de bureau, j'ai jamais vu un compilateur croisé permettant sur un même OS de compiler mon appli pour la faire tourner sous Windows, Linux, Mac et autres ...

C'est alors que tu as mal cherché...

La collection Gcc, par exemple, est tout à fait capable d'effectuer une cross compilation en n'ayant, en définitive "qu'à" indiquer le compilateur adapté pour le système cible

La c'est plus d'api du système que de compilateur à proprement parlé.

Porter une appli d'un unix vers un autre (même si l'archi du proc change) est beaucoups plus simple que de porter d'un unix vers windows.

au passage gcc peu etre croisé.

Et encore...

Avec Gcc, par exemple, l'architecture cible peut être définie comme option de compilation ( -march )

Pour le reste, si tu veilles à utiliser les en-têtes standards, tu n'auras, comme je viens de le dire qu'à spécifier quel compilateur utiliser en fonction de la cible voulue

[jabbounet]

C'est alors que tu as mal cherché...

Avec Gcc, par exemple, l'architecture cible peut être définie comme option de compilation ( -march )

c'est pour cela que j'ai dit que gcc pouvait être croisé.

[kpouer]

gcc peut être croisé oui surement mais ca reste très théorique tout ca à part si on fait un petit projet console sans dépendances.
Exemple : prend les sources de VLC, met toi sous Windows et build moi un VLC pour Mac OS X ou pour Linux.
Si tu sais faire j'ai hate d'avoir le tutorial

[jabbounet]

gcc peut être croisé oui surement mais ca reste très théorique tout ca à part si on fait un petit projet console sans dépendances.
Exemple : prend les sources de VLC, met toi sous Windows et build moi un VLC pour Mac OS X ou pour Linux.
Si tu sais faire j'ai hate d'avoir le tutorial

Des solutions de compilateurs croisées (gcc et autre) existent et sont / ont été couramment utilisé dans l'embarqué.

Exemple:
quand je faisais de l'ada dans le ferroviaire je développais sous une machine unix (SunOS a base de sparc) et les systèmes cibles étais soit des calculateur a base de 68000 (avec un kernel propriétaire) soit des 8086/pentium sous vxworks donc des archi de processeur/os qui n'avaient pas grand chose en commun et c'était il y'a 8 ans.

et je pense que cela se fait toujours dans ce secteur.

hier ou avant hier il y'a eu un topic sur une personne qui cherchait a debugger son programme en C et il utilisait un gcc croisé.
https://www.developpez.net/forums/d7...ignal-sigsegv/


donc oui c'est de la théorie bien appliquée je trouve

[kpouer]

Ba je t'ai donné un exemple concret et je peux en donner des centaines d'autres.
Il faut vraiment être dans des cas très particuliers pour que ca marche

[jabbounet]

Ba je t'ai donné un exemple concret et je peux en donner des centaines d'autres.
Il faut vraiment être dans des cas très particuliers pour que ca marche

je viens aussi de t'en donner. en updatant mon post....

le cas particulier etant que tu pense plus a ta cible qu'a ton hote. mais c'est loin d'être particulier en embarqué

[jabbounet]

Ba je t'ai donné un exemple concret et je peux en donner des centaines d'autres.
Il faut vraiment être dans des cas très particuliers pour que ca marche

et il faut penser portabilité des le départ aussi, mais il y'a un nombre important d'appli qui tourne sous windows et sous linux (Gimp, ls, grep, bash, firefox, ... )

je ne crois pas que ces applis soit toutes en java

[kpouer]

Ba faut bien penser à la cible.
Et c'est le cas de toute application desktop.
Si tu connais une seule appli desktop (disons opensource et un peu connu, pas une fenetre hello world) marchant sur Mac, linux, Windows et compilable avec une unique machine avec un cross compiler, j'aimerai le savoir.

Je dis pas que les cross compiler existent pas, je dis juste que sur ce point au moins java a l'avantage de simplifier la vie du développeur, car en java je connais un tas d'appli tournant sur les 3 OS principaux et dont les développeurs n'ont pas de Mac ou pas de Windows.

et il faut penser portabilité des le départ aussi, mais il y'a un nombre important d'appli qui tourne sous windows et sous linux (Gimp, ls, grep, bash, firefox, ... )

je ne crois pas que ces applis soit toutes en java

oui je ne dis pas le contraire je dis juste que la portabilité est plus facile en java et la compilation n'en parlons même pas.
Une fois de plus je pense pas que Gimp ou Firefox soient compilés avec des cross compiler, je pense que la version linux est compilée sous linux et la version Windows est compilée sous Windows, et que si tu veux compiler la version Windows sous linux tu vas en baver

[jabbounet]

Ba faut bien penser à la cible.
Et c'est le cas de toute application desktop.
Si tu connais une seule appli desktop (disons opensource et un peu connu, pas une fenetre hello world) marchant sur Mac, linux, Windows et compilable avec une unique machine avec un cross compiler, j'aimerai le savoir.

C'est aussi une raison de cout, un cross compiler ça coute plus cher qu'un pc en général. donc effectivement quand tu fait un appli desktop tu te paye 3 serveur un dans chaque os et tu compile localement.

Je dis pas que les cross compiler existent pas, je dis juste que sur ce point au moins java a l'avantage de simplifier la vie du développeur, car en java je connais un tas d'appli tournant sur les 3 OS principaux et dont les développeurs n'ont pas de Mac ou pas de Windows

principaux dans le monde bureautique/multimédia, pas vraiment dans le monde temps réél embarqué.

[Alp]

gcc peut être croisé oui surement mais ca reste très théorique tout ca à part si on fait un petit projet console sans dépendances.
Exemple : prend les sources de VLC, met toi sous Windows et build moi un VLC pour Mac OS X ou pour Linux.
Si tu sais faire j'ai hate d'avoir le tutorial

http://tcuvelier.developpez.com/#cross-gcc

L'auteur des articles explique même comment cross-compiler Qt...

[jabbounet]

Ceci dit je viens de tomber sur un post ou certaines personnes ont tenté de cross compiler firefox sur ARM

http://markmail.org/message/kj7sen5lrwpgxkzc