PUTAIN J'AI JAMAIS ETE AUSSI CON! - Page 1

j'ai passé 3/4h à chercher
et mon erreur venait de là!

final private int MODE_ADDPOINT=0;
final private int MODE_MOVEPOINT=1;
final private int MODE_REMOVEPOINT=2;
final private int MODE_INSERTPOINT=2;

huhuhuhuuhuhu

vive les enums, en C/C++, pour ça, qui mettent automatiquement une valeur différente pour chaque identifiant

c'est toujours les trucs les plus cons qui prennent le plus de temps

java suxx c# powa ^^

lol
je comprenais pas aussi pourquoi ça m'enlevait des points de ma courbe!

je crois qu'il y a des enum en java en fait

ouais mais c'est dans la version 5.0 beta seulement donc bon c po compatib

Une méthode de programmation rigoureuse permettant d'éviter ce genre d'erreur serait :

[code]
final private int MODE_ADDPOINT = 0;
final private int MODE_MOVEPOINT = MODE_ADDPOINT+1;
final private int MODE_REMOVEPOINT = MODE_ADDPOINT+MODE_MOVEPOINT+1;
final private int MODE_INSERTPOINT = MODE_ADDPOINT+MODE_MOVEPOINT+MODE_REMOVEPOINT+1;[/code]

Grâce à l'indentation croissante, tu vois en seul coup d'oeil si ton initialisation est valable. Bien sûr, ca reste de l'ordre du "bricolage", mais il faut bien se dire que la valeur des constantes n'importe pas en langages objet.

a peine incognito, sacre patrick

PAtrick faisant du java

SmHd^2> ce serait plus propre, moins moche qd tu dois définir 50 constantes, et avec des valeurs moins funky (pas de numérotation en O(n^2) ) avec :

final private int MODE_ADDPOINT    = ENUM_ZERO+1;
final private int MODE_MOVEPOINT   = MODE_ADDPOINT+1;
final private int MODE_REMOVEPOINT = MODE_MOVEPOINT+1;
final private int MODE_INSERTPOINT = MODE_REMOVEPOINT+1;

ou encore, autre truc :

final private int MODE_ADDPOINT=0; // enum
final private int MODE_MOVEPOINT=1; // enum
final private int MODE_REMOVEPOINT=2; // enum
final private int MODE_INSERTPOINT=3; // enum

et grep '//.*\<enum\>.*$' **/*.java|cut -d= -f2|cut -d; -f1|perl -ne 'die""if!/(\d+)/;$1||$1==$m+1||die"bad enum!";$m=$1' dans le makefile... (éventuellement remplacer **/*.java par les fichiers à donner en pâture à javac)

A. OK pour le "moins moche". Mais dans le cas d'une énumération courte, je conseille "ma" méthode. Car "ta" méthode présente l'inconvénient de ne pas supprimer les erreurs potentielles de copier coller Le problème reste le même.

B. Bon courage. NE pas oublier de faire une copie du projet avant de lancer un truc comme ça (je parle d'expérience )

smeet :
A. OK pour le "moins moche". Mais dans le cas d'une énumération courte, je conseille "ma" méthode. Car "ta" méthode présente l'inconvénient de ne pas supprimer les erreurs potentielles de copier coller Le problème reste le même.

Ben le fait d'aligner verticalement fait qu'on voit tt de suite si 2 trucs consécutifs sont pareils...

B. Bon courage. NE pas oublier de faire une copie du projet avant de lancer un truc comme ça (je parle d'expérience )

Mais non, c juste un truc pour vérifier, pas pour modifier le code ^^

mince, c'etait smeet, une chance sur 2

liquid :
mince, c'etait smeet, une chance sur 2

Ca ressemblait pas trop à du PpHd, qd même

c clair que PpHd faisant de l'objet ca me paraissait byzarre

Le mieux reste d'utiliser un IDE puissant avec un open tool adéquat.

lol ouais c'était byzarre (en même tps faut être ici depuis un moment pour comprendre le gras lol)
je me disais bientôt une implémentation de J2ME sur Pedrom lol

vos solutions sont pas mal
mais la meilleure reste de ne pas copier coller sans réfléchir comme une mégasoume

smeet :
Le mieux reste d'utiliser un IDE puissant avec un open tool adéquat.

voire même carrément un langage puissant, c encore mieux

Je ne vois pas en quoi c'est puissant que le langage t'initialise lui même tes variables avec des valeurs différentes. On suppose que t'es suffisamment intelligent pour le faire toi même. Mais en cherchant bien, il dois exister un design pattern permettant d'initialsier des variables d'énumération en Java Pur.

smeet
:Je ne vois pas en quoi c'est puissant que le langage t'initialise lui même tes varaibles avec des valeurs différentes. On suppose que t'es suffisamment intelligent pour le faire toit même.

#mac#
Accessoirement, le hack d'utiliser des ints pour ça :

* n'utilise pas le typage (et donc le compilo n'y verra que du feu si tu intervertis MODE_MOVEPOINT et WEAPON_SHOTGUN dans l'ordre des args d'une fonction... [remarque, ça peut être un bon moyen de faire du code obfuscaté ça ] )

* t'oblige à tout définir manuellement, d'où risques d'erreurs à la con comme ./1

* ne fournit absolument aucune métadonnée, par exemple lorsque tu voudras écrire qqpart "je suis dans le mode InsertPoint", ben tu vas devoir réécrire une fonction (d'où risque d'erreur, et prise de tête parce que chaque identifiant apparaît 3x et pas une fois seulement, qui plus est à des endroits potentiellement loins dans le code, et en plus à chaque fois tu es obligé de rajouter un préfixe pour faire un nom unique, ce qui n'est pas nécessaire en C# puisque les enums sont dans leurs propre namespace)

Et puis bon, si Sun a décidé d'en mettre finalement, c p-ê pas pour rien

* n'utilise pas le typage (et donc le compilo n'y verra que du feu si tu intervertis MODE_MOVEPOINT et WEAPON_SHOTGUN dans l'ordre des args d'une fonction... [remarque, ça peut être un bon moyen de faire du code obfuscaté ça ] )

Oui, je suis d'accord. Si tu veux faire une énumération propre, tu utilises les objets à ta disposition. Par extension, je dirais qu'on ne peut pas faire de la programmation "propre" en Java si on continue d'utiliser les types primitifs (celà dit, j'admets qu'ils sont bien pratiques ^^).

* t'oblige à tout définir manuellement, d'où risques d'erreurs à la con comme ./1

Le problème ici vient du programmeur. Il n' existe pas encore de langage qui code à ta place. Alors si tu fais des erreurs cons, tu assumes, c'est pour ta pomme, et non pas la faute du langage. *

* ne fournit absolument aucune métadonnée, par exemple lorsque tu voudras écrire qqpart "je suis dans le mode InsertPoint", ben tu vas devoir réécrire une fonction (d'où risque d'erreur, et prise de tête parce que chaque identifiant apparaît 3x et pas une fois seulement, qui plus est à des endroits potentiellement loins dans le code, et en plus à chaque fois tu es obligé de rajouter un préfixe pour faire un nom unique, ce qui n'est pas nécessaire en C# puisque les enums sont dans leurs propre namespace)

rien compris...

smeet
:

* n'utilise pas le typage (et donc le compilo n'y verra que du feu si tu intervertis MODE_MOVEPOINT et WEAPON_SHOTGUN dans l'ordre des args d'une fonction... [remarque, ça peut être un bon moyen de faire du code obfuscaté ça ] )

Oui, je suis d'accord. Si tu veux faire une énumération propre, tu utilises les objets à ta disposition. Par extension, je dirais qu'on ne peut pas faire de la programmation "propre" en Java si on continue d'utiliser les types primitifs (celà dit, j'admets qu'ils sont bien pratiques ^^).

Bah c simple, si la solution propre prend 2x plus de lignes, c tellement lourd qu'on ne la choisit pas => oui, c théoriquement possible, mais en pratique le langage ne permet pas vraiment de faire des trucs propres... Parce que tu peux aussi prendre un mauvais langage et dire que tout ce qui est possible dans un bon langage l'est aussi dans le mauvais langage puisqu'on peut faire un interpréteur pour ce bon langage Sauf qu'en pratique, c tellement lourd qu'on reste sur le mauvais langage...

Sans compter que le fait de wrapper dans un objet rend le truc bcp plus lourd... (garbage collection, etc...). Et comme Java ne fournit pas de struct, DTC

* t'oblige à tout définir manuellement, d'où risques d'erreurs à la con comme ./1

Le problème ici vient du programmeur. Il n' existe pas encore de langage qui code à ta place. Alors si tu fais des erreurs cons, tu assumes, c'est pour ta pomme, et non pas la faute du langage. *

Mais c vrai, toutes les erreurs viennent du programmeur ! Franchement, le typage, ça sux complètement, on devrait tout coder avec des offsets comme en ASM, et sans aucun typage Si tu te plantes dans les offsets ou que tu déréférences pas alors qu'il fallait le faire, "tu assumes, c'est pour ta pomme"

Euh t'en as d'autres, des comme ça ?

* ne fournit absolument aucune métadonnée, par exemple lorsque tu voudras écrire qqpart "je suis dans le mode InsertPoint", ben tu vas devoir réécrire une fonction (d'où risque d'erreur, et prise de tête parce que chaque identifiant apparaît 3x et pas une fois seulement, qui plus est à des endroits potentiellement loins dans le code, et en plus à chaque fois tu es obligé de rajouter un préfixe pour faire un nom unique, ce qui n'est pas nécessaire en C# puisque les enums sont dans leurs propre namespace)

rien compris...

En C#, tu écrirais

enum Mode { AddPoint, MovePoint, RemovePoint, InsertPoint }

Mode mode;
string WhereAmI() {
  return "je suis dans le mode "+mode;
}

L'équivalent en Java, c :

final private int MODE_ADDPOINT=0;
final private int MODE_MOVEPOINT=1;
final private int MODE_REMOVEPOINT=2;
final private int MODE_INSERTPOINT=3;

int mode;
String WhereAmI() {
  String s="java sux";
  if (mode==MODE_ADDPOINT)
    s="ADDPOINT";
  else if (mode==MODE_ADDPOINT)
    s="ADDPOINT";
  else if (mode==MODE_ADDPOINT)
    s="ADDPOINT";
  else if (mode==MODE_ADDPOINT)
    s="ADDPOINT";
  return "je suis dans le mode "+s;
}

Compare le nb de lignes

je crois que dans le jdk 5.0 ça se passe comme ça chez mcdonalds

1.5, oui... Mais je voulais surtout répondre au gros !mac de smeet ^^

janjan2
: PUTAIN J'AI JAMAIS ETE AUSSI CON!

"No, you aren't. Everyone makes logical mistakes ("thinkos") from time to time..." ©

mon erreur n'est pas d'avoir écrit cette connerie mais de ne pas l'avoir vu tout de suite et de ne même pas y avoir pensé
"this is more a self confidence exess than a logical error " ©

pk "©" ?

smeet :
Le mieux reste d'utiliser un IDE puissant avec un open tool adéquat.

j'utilise netbeans, parce que je le vauz bienz

Et comme Java ne fournit pas de struct

Y'a un truc, ca s'appelle des classes.

final private int MODE_ADDPOINT=0;
final private int MODE_MOVEPOINT=1;
final private int MODE_REMOVEPOINT=2;
final private int MODE_INSERTPOINT=3;

int mode;
String WhereAmI() {
String s="java sux";
if (mode==MODE_ADDPOINT)
s="ADDPOINT";
else if (mode==MODE_ADDPOINT)
s="ADDPOINT";
else if (mode==MODE_ADDPOINT)
s="ADDPOINT";
else if (mode==MODE_ADDPOINT)
s="ADDPOINT";
return "je suis dans le mode "+s; }

Cette fonction ne sert à rien. Et puis, si tu utilises des int, autant les utiliser comme index d'un array de string, non?
Par ailleurs, en informatique, peut importe la taille des fichiers, c'est vraiment al derniere chose qui compte. Ce qui importe est, au choix, la rapidité, ou le haut-niveau. Java est haut niveau. Ca prend beaucoup de lignes, c'est comme ca.

Bref, j'ai l'impression que tu cherches une argumentation pour descendre Java, mais il te faudrait un peu plus les travailler

smeet
:

Et comme Java ne fournit pas de struct

Y'a un truc, ca s'appelle des classes.

Ah, qu'est-ce donc ?
Nan mais tu noteras que c'était dans un paragraphe qui concernait la performance du code, hein... Le C# fournit (en plus des classes, oui ) un moyen de faire des structures de données qui se comportent en tout point comme des "int", par exemple : allocation sur la pile/dans les registres et pas sur le tas, passage par valeur et non par référence, etc (et il se trouve que ces structures de données s'appellent struct). Si tu passes par une classe wrapper, alors tu vas te chopper tout l'overhead de la garbage collection : au lieu de stocker un entier sur 8, 16 ou 32 bits, tu vas être obligé de stocker un pointeur 32 bits, qui va lui-même devoir pointer sur un autre bloc de mémoire, lequel va probablement devoir contenir une virtual function table et la valeur qui t'intéresse. Donc il y a des chances que si tu veux optimiser ton prog et que tu n'aies pas de type struct, tu sois obligé de passer par des int...
Et tu ne réponds pas au reste du paragraphe ^^

final private int MODE_ADDPOINT=0;
final private int MODE_MOVEPOINT=1;
final private int MODE_REMOVEPOINT=2;
final private int MODE_INSERTPOINT=3;

int mode;
String WhereAmI() {
String s="java sux";
if (mode==MODE_ADDPOINT)
s="ADDPOINT";
else if (mode==MODE_ADDPOINT)
s="ADDPOINT";
else if (mode==MODE_ADDPOINT)
s="ADDPOINT";
else if (mode==MODE_ADDPOINT)
s="ADDPOINT";
return "je suis dans le mode "+s; }

Cette fonction ne sert à rien.

(euh j'ai oublié de préciser que j'avais eu la flemme de changer ADDPOINT par les 3 autres trucs, évidemment)
Euh, tu fais exprès, rassure-moi ?
Ca ne sert à rien pour un désassembleur d'écrire le nom des opcodes qu'il génère ? Ca ne sert à rien de pouvoir débugger un prog sans avoir à faire à la main ce genre de conversions ? (surtout que s'il s'agit de voir un log de debug d'une vieille version, les numéros peuvent très bien ne plus correspondre) Et j'en passe...

Et puis, si tu utilises des int, autant les utiliser comme index d'un array de string, non?

Bah oui, si tu veux, mais le truc c que pour le coup si tu oublies de mettre à jour l'un alors que tu modifies l'autre, tu te retrouves avec un truc qui fait n'importe quoi... Et accessoirement avec ta technique pour affecter les numéros qui fait enum_value[n]=n*(n+1)/2, le tableau risque de devenir assez vite gigantesque (et je ne parle même pas d'essayer d'insérer un élément au milieu, sachant que le nb de blancs qu'il doit y avoir entre 2 éléments de l'énum dépend de la position de cet élément, il faut tout refaire )

Par ailleurs, en informatique, peut importe la taille des fichiers, c'est vraiment al derniere chose qui compte. Ce qui importe est, au choix, la rapidité, ou le haut-niveau.

Oui, je suis d'accord.

Java est haut niveau. Ca prend beaucoup de lignes, c'est comme ca.

Euh là par contre c'est n'importe quoi.
- OK, on s'en fout que le source prenne 30 Mo, mais par contre si le fait que ça prenne 30 Mo nuit à la lisibilité ou à la maintenabilité, ça devient n'importe quoi... (parce que tu ne vas pas me dire qu'avoir exactement la même chose 2 ou 3x dans le code est qqch qui accroît la lisibilité ou réduit le risque d'erreur : au contraire, au moindre oubli de modification d'un de ces éléments, le truc par en vrille -- et si on ne s'en rend pas compte tt de suite, ça peut être assez dur à trouver)
- ensuite, de ce point de vue-là, Java n'est justement pas haut niveau puisqu'il empêche d'adopter un typage efficace et oblige à passer par des objets sémantiquement plus pauvres (cf par exemple la différence entre la lib std de Java où chaque objet différent a un type différent, par opposition à la lib std du C où 90% des types sont des int, des void* ou des char* -- cf le système de fichiers de Java vs le système de file descriptors d'Unix), qui ne changent rien en bas niveau mais qui permettent des choses plus concises et plus sûres en haut niveau

Bref, j'ai l'impression que tu cherches une argumentation pour descendre Java, mais il te faudrait un peu plus les travailler

N'importe quoi Au contraire, c'est pas vraiment une critique sur Java puisque l'absence d'énum a été corrigée. C'est plutôt une critique sur le fait que tu dises que les énum sont inutiles...