[Débat] C++ vs Java

Citation:

---

Envoyé par adiGuba

Mais on a également la possibilité de parcourir facilement les valeurs d'une enum voir de faire la conversion String -> enum :

Code:

---

1 2 3 4

for (MyEnum e : MyEnum.values()) { System.out.println(e); } MyEnum.valueOf("A"); // retourne MyEnum.A

---

---

Et tu peux même ajouter une méthode de conversion de String en enum dans la classe de l'enum, toujours plus joli qu'avoir une méthode qui se balade toute seule dans un coin

Citation:

---

Envoyé par jabbounet

Oui mais ce n'est pas un objet, si je veux le gérer par objet je peux le faire en implémentant une classe par dessus mais je ne suis pas obligé. j'ai le choix quoi :D

---

Qu'est ce que ca change que ce soit un objet ou un int ? En quoi ton int est mieux ?

Citation:

---

Qu'est ce que ca change que ce soit un objet ou un int ? En quoi ton int est mieux ?

---

moins d'occupation en mémoire (32bits uniquement), plus facile a gérer, évite d'avoir à le passer par référence dans les fonction/méthodes/ de plus il est plus proche de la machine....

Après cela me laisse le choix si je veux que ce soit géré par un objet je met une classe autour, mais j'ai rarement besoin de l'objet pour gérer un enum car j'ai plutôt tendance a être proche du système dans mon boulot. ensuite a plus haut level je ne dit pas, mais perso l'objet autour de enum je n'en ai pas vraiment l'usage.


je crois qu'il y'a déjà eu plusieurs page de débat sur le sujet :D

Citation:

---

Envoyé par spidermario

D'ailleurs, ça existe.
kisitomomotene, tous les langages machines ne sont pas équivalents, et dire que "le langage natif de tout processeur est le langage machine" ne prouve pas que pour un certain processeur, le langage natif ne puisse être le bytecode Java.

---

je cite wiki "A Java processor is the implementation of the Java Virtual Machine (JVM) in hardware"
Et c'est bien ce que j'avais dis. Je le redis encore: Le véritable langage natif de tout processeur c'est le langage binaire (a moins que l'informatique n'est changé..) et tout autre langage supporté "nativement" par le processeur necessit une machine virtuelle ou un compilateur, et ces éléments "allourdissent" le processeur.

Citation:

---

Et c'est bien ce que j'avais dis. Je le redis encore: Le véritable langage natif de tout processeur c'est le langage binaire (a moins que l'informatique n'est changé..) et tout autre langage supporté "nativement" par le processeur necessit une machine virtuelle ou un compilateur, et ces éléments "allourdissent" le processeur.

---

Au risque de dire une connerie il me semble que le bytecode est aussi un langage binaire censé être compris par la "machine virtuelle" java....
Donc concevoir un processeur qui comprend nativement ce language binaire ne me parait pas être un non sens.

si tu regarde un peux les specs de la jvm
http://java.sun.com/docs/books/jvms/...onics.doc.html

tu retrouvera des concept proche de ce que tu peux voir sur les instruction en assembleur pour un microprocesseur standard

Citation:

---

Envoyé par jabbounet

moins d'occupation en mémoire (32bits uniquement), plus facile a gérer, évite d'avoir à le passer par référence dans les fonction/méthodes/ de plus il est plus proche de la machine....

Après cela me laisse le choix si je veux que ce soit géré par un objet je met une classe autour, mais j'ai rarement besoin de l'objet pour gérer un enum car j'ai plutôt tendance a être proche du système dans mon boulot. ensuite a plus haut level je ne dit pas, mais perso l'objet autour de enum je n'en ai pas vraiment l'usage.


je crois qu'il y'a déjà eu plusieurs page de débat sur le sujet :D

---

Moins d'occupation mémoire, ca me parrait négligeable, dans un enum il n'y a qu'une seule instance de chaque valeur de l'enum (cette instance ne contient a peu près rien de plus que ton integer à part peut être le label de chaque valeur), donc la différence si on avait pris un int va représenter quelques octets stockés une unique fois dans la JVM, jamais dupliqués puisqu'on ne recopie jamais les objets passés en paramètres en java.
L'objet autour de l'enum peut servir au debug par exemple (afficher dans une trace un nom plutot qu'un simple nombre)

Citation:

---

Moins d'occupation mémoire, ca me parrait négligeable, dans un enum il n'y a qu'une seule instance de chaque valeur de l'enum (cette instance ne contient a peu près rien de plus que ton integer à part peut être le label de chaque valeur), donc la différence si on avait pris un int va représenter quelques octets stockés une unique fois dans la JVM, jamais dupliqués puisqu'on ne recopie jamais les objets passés en paramètres en java.

---

parce que tu travail en ciblant des hardware avec des giga de ram, ce n'est pas le cas de tout le monde. saurait tu faire tourner une console de train avec moins de 16 mega de ram en java (projet sur lequel j'ai travaillé il y'a quelques années)?

Citation:

---

Envoyé par jabbounet

parce que tu travail en ciblant des hardware avec des giga de ram, ce n'est pas le cas de tout le monde. saurait tu faire tourner une console de train avec moins de 16 mega de ram en java (projet sur lequel j'ai travaillé il y'a quelques années)?

---

C'est sur, la différence n'est que de quelques octets, à part si tu programme le microcode d'un ascenceur ou d'une cafetière la différence n'a pas grande importance.
Regarde le stockage d'un booléen, ca va te prendre 32 bits pour stocker 1 seul bit.
T'en stocke 10 dans ton soft et t'as déjà perdu plus de place qu'avec l'enum en objets :aie:
Sauf bien sur si tu joues a manipuler les bits pour stocker effectivement 32 booléens dans un integer, mais bon faut vraiment en avoir très besoin

edit : sinon ta console de trail je sais pas j'en ai jamais programmé. Mais oui faire un soft prenant moins de 16 Mo en java est parfaitement faisable, le soucis c'est la JVM qui en ajoute 10 au programme

Citation:

---

C'est sur, la différence n'est que de quelques octets, à part si tu programme le microcode d'un ascenceur ou d'une cafetière la différence n'a pas grande importance.
Regarde le stockage d'un booléen, ca va te prendre 32 bits pour stocker 1 seul bit.
T'en stocke 10 dans ton soft et t'as déjà perdu plus de place qu'avec l'enum en objets
Sauf bien sur si tu joues a manipuler les bits pour stocker effectivement 32 booléens dans un integer, mais bon faut vraiment en avoir très besoin

---

Cela dépend de comment tu organise ta mémoire met tu as moyen de gérer jusqu'a 32 booléens avec 32 bits (tu peux le faire en C, mais aussi en Ada avec le pragma pack). et dans le genre de soft dont je te parle tu en as effectivement très très besoin

Après effectivement quand tu bosse sur une machine avec 24 cpu et a peu près autant de go de ram tu peux te permettre d'être un peu plus laxiste sur ton occupation mémoire.

Citation:

---

Envoyé par jabbounet

Après effectivement quand tu bosse sur une machine avec 24 cpu et a peu près autant de go de ram tu peux te permettre d'être un peu plus laxiste sur ton occupation mémoire.

---

Tu caricatures, je veux bien croire que certains cas font que 100 octets (et je parle pas de 100 octets alloués 36 fois, je parle juste de 100 octets alloués une seule fois) de plus ou de moins c'est terrible, mais dans la majorité des cas c'est négligeable

Personnellement j'ai connu ces deux mondes et je caricature a peine.

Quand tu passe d'un endroit (développement SIL 4 embarqué ferroviaire) ou le moindre octet utilisé compte et que l'utilisation mémoire est évalué dans les document de spec / conception (et je ne plaisante pas, une estimation peu être requise avant le codage pour dimensionner le système ou vérifier que cela respectera les contraintes), pour arriver dans un autre (télécom) ou tu as (gros serveur / SGBD oracle, système à 24 cpu) ça te fait tout drôle.

Citation:

---

Envoyé par Tommy31

Donc la portabilité du C++ est dépendante des bibliothèques tierces dont la capacité de portage varie de l'une à l'autre. Ce n'est pas systématiquement le cas en java, où le jdk pourvoit à la plupart des besoins.

---

Effectivement, la portabilité d'une bibliothèque tierce dépend, en C++, du "bon vouloir" du programmeur qui l'a codée...

Et j'admets que c'est, en gros, le problème récurrent de l'ensemble des langages compilés ;)

Mais je demande alors à ceux qui défendent le java (bien que je préfère C++ à titre personnel, je ne prend pas parti quant à savoir quel langage est le meilleur;)) de rester honnêtes et d'admettre le fait que c'est parce que les éditeurs de machines virtuelles font l'effort d'en écrire pour les différents système que les langages à base de bytecode permettent cette compatiblité "intrinsèque"

... Evidemement, je ne prend pas en compte les processeur capable d'utiliser nativement le bytecode ;)

Citation:

---

Envoyé par koala01

Effectivement, la portabilité d'une bibliothèque tierce dépend, en C++, du "bon vouloir" du programmeur qui l'a codée...

Et j'admets que c'est, en gros, le problème récurrent de l'ensemble des langages compilés ;)

Mais je demande alors à ceux qui défendent le java (bien que je préfère C++ à titre personnel, je ne prend pas parti quant à savoir quel langage est le meilleur;)) de rester honnêtes et d'admettre le fait que c'est parce que les éditeurs de machines virtuelles font l'effort d'en écrire pour les différents système que les langages à base de bytecode permettent cette compatiblité "intrinsèque"

... Evidemement, je ne prend pas en compte les processeur capable d'utiliser nativement le bytecode ;)

---

C'est sur java est portable d'une JVM a une autre, si on a pas de JVM on est mal :mrgreen:

Citation:

---

Envoyé par kpouer

C'est sur java est portable d'une JVM a une autre, si on a pas de JVM on est mal :mrgreen:

---

Et c'est pour ça que pour moi C ou C++ resteront longtemps "plus portables" que Java. Par contre l'avantage énorme de Java est que si une JVM est présente, en prenant quelques précautions on n'a pas besoin de recompiler.

Citation:

---

Envoyé par kpouer

C'est sur java est portable d'une JVM a une autre, si on a pas de JVM on est mal :mrgreen:

---

Aussi, mais, ce sur quoi je voulais surtout insister, c'est sur le fait que, si l'éditeur de JVM ne fait pas lui-même l'effort d'assurer qu'elle peut fonctionner sur plusieurs plateformes, le problème de compatiblité réapparait très rapidement ;)

Finalement, ce n'est que parce que Sun et d'autres fournissent des exécutables de JVM pour les différentes plateformes que tu peux envisager d'utiliser ton application java partout ;)...

Si, la crise aidant, on en arrivait (sait on jamais ;)) à ne plus avoir qu'un seul éditeur de JVM qui se foute pas mal d'en fournir une version pour windows, on serait mal :D (troll inside ...Et encore :aie:)

Oui mais l'avantage de java c'est qu'on a juste besoin qu'un seul se fasse chier a faire une JVM partout et ensutie a peu près tous les programmes suivent. Dans des langages type C++, c'est à chaque développeur de faire l'effort, et encore visiblement c'est pas si simple quand on voit le nombre de softs linux qui ne tournent pas sous Windows alors qu'il y a de la demande (et inversement des softs Windows qui ne tournent pas sous linux alors que l'éditeur est motivé pour le faire)

Citation:

---

Envoyé par kpouer

Oui mais l'avantage de java c'est qu'on a juste besoin qu'un seul se fasse chier a faire une JVM partout et ensutie a peu près tous les programmes suivent.

---

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

Citation:

---

Dans des langages type C++, c'est à chaque développeur de faire l'effort, et encore visiblement c'est pas si simple quand on voit le nombre de softs linux qui ne tournent pas sous Windows alors qu'il y a de la demande (et inversement des softs Windows qui ne tournent pas sous linux alors que l'éditeur est motivé pour 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é ;)

Aussi étrange que cela paraisse certaines version ancienne d'ie tournaient sous unix :D

la portabilité d'un soft est un choix fait dès les phase de spécification/conception voir même avant (cdc)

Ensuite elle dépend beaucoup de ta cible au départ, si tu fais un soft embarqué pour une procésseur spécifique même si tu pense a faire un code portable ce ne sera pas ta priorité, et quand tu changera de proc tu aura quelques surprise (genre migration d'un proc 68000 vers un 8086 avec le big endian et le little endian).

Maintenant si tu développe un système type sgdb et que tu veux le vendre a un maximum de cible tu vas l'imposer comme une contrainte forte de ton appli, et tu incluera des test sur plusieurs plate forme différente dans ton plan de test.

Citation:

---

Envoyé par jabbounet

Aussi étrange que cela paraisse certaines version ancienne d'ie tournaient sous unix :D

---

Normal, le code était le code original de Mosaic (comme Netscape V1) :P

(que M$ s'est empressé de faire payer)..

Citation:

---

Envoyé par jabbounet

Maintenant si tu développe un système type sgdb et que tu veux le vendre a un maximum de cible tu vas l'imposer comme une contrainte forte de ton appli, et tu incluera des test sur plusieurs plate forme différente dans ton plan de test.

---

:aie:

Ce devrait être le cas..


Nous voyons tous tous les jours que cela ne l'est pas ..

Citation:

---

Envoyé par souviron34

Normal, le code était le code original de Mosaic (comme Netscape V1) :P

(que M$ s'est empressé de faire payer)..

---

Oui, comme beaucoup d'entreprise, le but est de faire de l'argent.