Arto_8000
Messages postés1044Date d'inscriptionlundi 7 mars 2005StatutMembreDernière intervention13 juillet 2010
-
9 mai 2010 à 06:06
maximelien
Messages postés40Date d'inscriptionjeudi 22 janvier 2009StatutMembreDernière intervention23 juin 2010
-
26 mai 2010 à 11:48
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
maximelien
Messages postés40Date d'inscriptionjeudi 22 janvier 2009StatutMembreDernière intervention23 juin 2010 26 mai 2010 à 11:48
Généré par un PHP ou fourni par une BDD.
maximelien
Messages postés40Date d'inscriptionjeudi 22 janvier 2009StatutMembreDernière intervention23 juin 2010 26 mai 2010 à 11:47
Bien que ce code soit avant tout dans les codes astuces, il y a cependant des applications pratiques.
Par exemple, le code est utilisable tel-quel(surtout pour la version StringTo(String)Hexa ) pour comparer le digest effectué par du PHP au digest d'une appli Java.
En l'occurrence, je l'utilise actuellement pour développer un SHA1 (sur J2ME) et certainement plus tard pour faire une comparaison avec le SHA1 généré par un PHP.
maximelien
Messages postés40Date d'inscriptionjeudi 22 janvier 2009StatutMembreDernière intervention23 juin 2010 24 mai 2010 à 15:47
Oui effectivement Julien tu aurais du lire et comprendre le code avant de répondre.
Je suis d'accord qu'intégrer ce code dans la version finale d'une appli sera à mon avis très rare.
Mais, comme je l'ai dit, c'est un code pour débutant qui est souvent demandé, certainement pour comprendre l'encodage et les contrôles à effectuer sur un String. En gros du débug.
Personnellement, je m'en suis servi un peu dans le développement d'un convertisseur XML-Objet. Comme j'ai vu que c'était demandé, je l'ai posté.
aze555666
Messages postés208Date d'inscriptionmardi 13 avril 2004StatutMembreDernière intervention26 janvier 2009 23 mai 2010 à 00:03
Julien -> sa fonction ne fait pas ça justement (quand je l'ai vue listée dans l'email hebdomadaire, c'est ce que j'ai cru, alors j'étais venu pour écrire ce que tu as écrit ... mais je me suis rendu compte que c'était pas ça)
De plus, ta 2eme ligne c'est pas très propre, j'aurais mi Interger.toString(num)
Par contre, j'avoue que j'ai des doutes quant à l'utilité de la fonction présentée dans la source...
cs_Julien39
Messages postés6414Date d'inscriptionmardi 8 mars 2005StatutModérateurDernière intervention29 juillet 2020371 22 mai 2010 à 19:06
C'est vraiment pas terrible, ce que tu fais peut se faire en une ligne
String to int : Integer.parseInt(num)
int to String : str = ''+num
maximelien
Messages postés40Date d'inscriptionjeudi 22 janvier 2009StatutMembreDernière intervention23 juin 2010 10 mai 2010 à 18:32
J'ai compté deux chars pour un nombre, car dans la plupart des cas ce sont des lettres qui sont représentées et donc leur valeur est contenue sur deux chiffres. Sachant que à priori en java il est possible d'attribuer une valeur de 0 à 65536 (même si sur mon Netbeans java affiche des ? dès que l'on dépasse les ~255).
maximelien
Messages postés40Date d'inscriptionjeudi 22 janvier 2009StatutMembreDernière intervention23 juin 2010 10 mai 2010 à 18:15
Exacte AZE. la valeur n'est pas justifiée j'aurai du mettre soit rien soit la taille finale approximative. Mais dans quelle mesure cela alter la performance ? Tu penses qu'une allocation supplémentaire intempestive change la performance dans le cas d'un StringBuffer ? Sachant que d'après ce que j'ai vue l'allocation d'un StringBuffer se fait par tableaux de 100 chars. Donc la question que je me pose, techniquement que le tableau soit adressé au début ou à n'importe quel moment ca ne change rien !??
aze555666
Messages postés208Date d'inscriptionmardi 13 avril 2004StatutMembreDernière intervention26 janvier 2009 10 mai 2010 à 17:26
Quand je vois ceci :
StringBuffer buff = new StringBuffer(text.length());//to safe memory - Limit gc requests
Je me demande pourquoi tu initialise à cette longueur alors que tu sais qu'il en faudra beaucoup plus. Dans le premier exemple, chaque caractère de la chaine initiale donne dans la chaine finale 1 + (longueur de l'entier retourné lors du cast char -> int).
Dans la 2eme exemple c'est pire.
maximelien
Messages postés40Date d'inscriptionjeudi 22 janvier 2009StatutMembreDernière intervention23 juin 2010 9 mai 2010 à 13:43
*pardon v1.5 ou ultérieure
maximelien
Messages postés40Date d'inscriptionjeudi 22 janvier 2009StatutMembreDernière intervention23 juin 2010 9 mai 2010 à 13:41
Merci pour tes remarques Arto.
J'ai corrigé la coquille.
Pour StringBuilder je ne connaissais pas, merci de m'en faire part. Apparemment c'est apparut à la v1.5 du J2SE. Pour ma part je programme surtout sur J2ME en ce moment (et en l'occurrence en multi-thread) donc j'ai surtout en tête les fonctions de bases de java puisque comme tu le sais, en J2ME, java est très allégé.
Ceci étant apparemment il n'y aurait juste qu'à remplacer StringBuffer par StringBuilder ? Donc :
Pour ceux qui utilisent une version ultérieur à la v1.5 et pour du non-multi-thread vous pouvez utiliser StringBuilder pour plus de rapidité.
Merci Arto
Arto_8000
Messages postés1044Date d'inscriptionlundi 7 mars 2005StatutMembreDernière intervention13 juillet 20107 9 mai 2010 à 06:06
Tu serais mieux d'utiliser la classe StringBuilder au lieu de StringBuffer. La seule différence qui existe entre ces deux classes est que StringBuffer est synchronisé ce qui est un peu plus lent à l'exécution que sa version non-synchronisée StringBuilder. La seule raison d'utiliser StringBuffer est si le buffer est partagé par plusieurs threads.
Aussi, il faudrait que tu corriges le bout de code qui manque à la fin de la première fonction. Il manque un return et un "}".
26 mai 2010 à 11:48
26 mai 2010 à 11:47
Par exemple, le code est utilisable tel-quel(surtout pour la version StringTo(String)Hexa ) pour comparer le digest effectué par du PHP au digest d'une appli Java.
En l'occurrence, je l'utilise actuellement pour développer un SHA1 (sur J2ME) et certainement plus tard pour faire une comparaison avec le SHA1 généré par un PHP.
24 mai 2010 à 15:47
Je suis d'accord qu'intégrer ce code dans la version finale d'une appli sera à mon avis très rare.
Mais, comme je l'ai dit, c'est un code pour débutant qui est souvent demandé, certainement pour comprendre l'encodage et les contrôles à effectuer sur un String. En gros du débug.
Personnellement, je m'en suis servi un peu dans le développement d'un convertisseur XML-Objet. Comme j'ai vu que c'était demandé, je l'ai posté.
23 mai 2010 à 00:03
De plus, ta 2eme ligne c'est pas très propre, j'aurais mi Interger.toString(num)
Par contre, j'avoue que j'ai des doutes quant à l'utilité de la fonction présentée dans la source...
22 mai 2010 à 19:06
String to int : Integer.parseInt(num)
int to String : str = ''+num
10 mai 2010 à 18:32
10 mai 2010 à 18:15
10 mai 2010 à 17:26
StringBuffer buff = new StringBuffer(text.length());//to safe memory - Limit gc requests
Je me demande pourquoi tu initialise à cette longueur alors que tu sais qu'il en faudra beaucoup plus. Dans le premier exemple, chaque caractère de la chaine initiale donne dans la chaine finale 1 + (longueur de l'entier retourné lors du cast char -> int).
Dans la 2eme exemple c'est pire.
9 mai 2010 à 13:43
9 mai 2010 à 13:41
J'ai corrigé la coquille.
Pour StringBuilder je ne connaissais pas, merci de m'en faire part. Apparemment c'est apparut à la v1.5 du J2SE. Pour ma part je programme surtout sur J2ME en ce moment (et en l'occurrence en multi-thread) donc j'ai surtout en tête les fonctions de bases de java puisque comme tu le sais, en J2ME, java est très allégé.
Ceci étant apparemment il n'y aurait juste qu'à remplacer StringBuffer par StringBuilder ? Donc :
Pour ceux qui utilisent une version ultérieur à la v1.5 et pour du non-multi-thread vous pouvez utiliser StringBuilder pour plus de rapidité.
Merci Arto
9 mai 2010 à 06:06
Aussi, il faudrait que tu corriges le bout de code qui manque à la fin de la première fonction. Il manque un return et un "}".