C'est une structure complexe que tu ne peux pas representer statiquement en memoire, elle depend tres fortement des besoins en ressources du programme.
Regardes le code des constructeurs, ca va pas pisser bien loin non plus. La partie la plus relou, c'est les pb d'encodages, qu'il faut adresser de toutes facons.
Une fonction native, intern() qui va bien evidemment dependre de l'endianness du processeur, donc c'est le seul truc que tu peux pas faire en java. Trop dur.
ils utilisent tous tout un tas de commidites pas forcement jolies pour que le developpeur n'ait plus a se soucier de la gestion des ressources qu'il a pourtant demandees.
Comme?
Java a une String immutable ce qui peut etre genant en effet (d'ou le string buffer), l'approche parait bonne, un objet immutable simple et peu gourmand tant que tu le tripatouilles et un truc dedie a la manipulation.
Et puis imagine deux secondes que ta classe string ne te plaise pas, tu la retouches comment, tu t'amuses a reimplementer ton compilo ?
Tu fournis ta propre classe String?
C'est tres tres vilain, c'est sur, mais ca va etre pareil en c++ si tu t'amuses a faire la meme connerie...
Le truc c'est que je n'ai encore jamais vu une seule reimplementation de la class String en Java.
En c++ par contre, hem hem...
Alors c'est possible parce que les chaines de base sont des char*, ce qui rend les choses possibles (en Java, faudrait passer son temps a convertir de user String a system String, ce qui tue un peu l'interet), mais ca aboutit a du code pourri et plombe qui utilise des fonctions des bois et paf le buffer overflow.
Et si ton type int te plait pas, tu fais quoi? Tu patches le compilo?
Faut etre serieux deux secondes, je veux bien que le java fasse le cafe, mais ca reste sale.
Sale?!?!
Au lieu de repeter des trucs que t'as lu dans des trolls a droite a gauche, explique moi ce qui est "sale" dans les string Java.
T'as le source juste au dessus, donc t'as juste a me pointer les endroits crades.
[^] # Re: bannir "connect"
Posté par thedude . En réponse au journal Banni de chez Microsoft.. Évalué à 5.
gne?
http://www.docjar.com/html/api/java/lang/String.java.html
char[] value : les caracteres eux memes
int offset: offset de debut de stockage dans value
int count: taille de la chaine
'tin c'est super complexe ca!!!
Regardes le code des constructeurs, ca va pas pisser bien loin non plus. La partie la plus relou, c'est les pb d'encodages, qu'il faut adresser de toutes facons.
Une fonction native, intern() qui va bien evidemment dependre de l'endianness du processeur, donc c'est le seul truc que tu peux pas faire en java. Trop dur.
ils utilisent tous tout un tas de commidites pas forcement jolies pour que le developpeur n'ait plus a se soucier de la gestion des ressources qu'il a pourtant demandees.
Comme?
Java a une String immutable ce qui peut etre genant en effet (d'ou le string buffer), l'approche parait bonne, un objet immutable simple et peu gourmand tant que tu le tripatouilles et un truc dedie a la manipulation.
Et puis imagine deux secondes que ta classe string ne te plaise pas, tu la retouches comment, tu t'amuses a reimplementer ton compilo ?
Tu fournis ta propre classe String?
C'est tres tres vilain, c'est sur, mais ca va etre pareil en c++ si tu t'amuses a faire la meme connerie...
Le truc c'est que je n'ai encore jamais vu une seule reimplementation de la class String en Java.
En c++ par contre, hem hem...
Alors c'est possible parce que les chaines de base sont des char*, ce qui rend les choses possibles (en Java, faudrait passer son temps a convertir de user String a system String, ce qui tue un peu l'interet), mais ca aboutit a du code pourri et plombe qui utilise des fonctions des bois et paf le buffer overflow.
Et si ton type int te plait pas, tu fais quoi? Tu patches le compilo?
Faut etre serieux deux secondes, je veux bien que le java fasse le cafe, mais ca reste sale.
Sale?!?!
Au lieu de repeter des trucs que t'as lu dans des trolls a droite a gauche, explique moi ce qui est "sale" dans les string Java.
T'as le source juste au dessus, donc t'as juste a me pointer les endroits crades.