Dans un livre (au coeur de java) je lis
N'employez jamais =3D=3D pour comprer des cha=EEnes, pourquoi ?
exemple
String hel=3D"Hel";
if (hel=3D=3D"Hel") me renvoie un true
if (hel.substring(0,3)=3D=3D"Hel") me renvoie aussi un true alors que
selon mon livre =E7a devrait me renvoyer un r=E9sultat probablement faux
Pourriez-vous me donner des exemples de r=E9pr=E9sentation d'unit=E9 de code
et de point de code ?
Dans tout ce que je lis, il y a beaucoup d'explication pompeuse et
aucun exemple. Je n'arrive pas =E0 bien saisir la diff=E9rence (pas de
lien, des exemples svp :D)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
cfranco
xfredox wrote:
Dans un livre (au coeur de java) je lis N'employez jamais == pour comprer des chaînes, pourquoi ? exemple String hel="Hel"; if (hel=="Hel") me renvoie un true if (hel.substring(0,3)=="Hel") me renvoie aussi un true alors que selon mon livre ça devrait me renvoyer un résultat probablement faux
Pourriez-vous me donner des exemples de réprésentation d'unité de code et de point de code ?
Là tu es tombé dans un cas particulier, parce que tu compares à une chaîne constante, et comme il y a unicité des objets String, ça marche...
Mais essaie plutôt :
String hel = "Hel"; String hel2 = "Hel";
Et compare le résultat de : if (hel == hel2) et de : if (hel.equals(hel2))
Au passage, petit truc "classique", quand on compare une chaîne à une chaîne constante, il est préférable d'écrire :
if (CONSTANTE.equals(maChaine))
plutôt que : if(maChaine.equals(CONSTANTE))
car si par malheur maChaine est null, on évite la nullPointerException (a supposer que l'on soit bien certain que CONSTANTE ne sera pas null, mais a priori c'est normalement le cas...)
-- Christophe Franco
xfredox <xfredox@free.fr> wrote:
Dans un livre (au coeur de java) je lis
N'employez jamais == pour comprer des chaînes, pourquoi ?
exemple
String hel="Hel";
if (hel=="Hel") me renvoie un true
if (hel.substring(0,3)=="Hel") me renvoie aussi un true alors que
selon mon livre ça devrait me renvoyer un résultat probablement faux
Pourriez-vous me donner des exemples de réprésentation d'unité de code
et de point de code ?
Là tu es tombé dans un cas particulier, parce que tu compares à une
chaîne constante, et comme il y a unicité des objets String, ça
marche...
Mais essaie plutôt :
String hel = "Hel";
String hel2 = "Hel";
Et compare le résultat de :
if (hel == hel2)
et de :
if (hel.equals(hel2))
Au passage, petit truc "classique", quand on compare une chaîne à une
chaîne constante, il est préférable d'écrire :
if (CONSTANTE.equals(maChaine))
plutôt que :
if(maChaine.equals(CONSTANTE))
car si par malheur maChaine est null, on évite la nullPointerException
(a supposer que l'on soit bien certain que CONSTANTE ne sera pas null,
mais a priori c'est normalement le cas...)
Dans un livre (au coeur de java) je lis N'employez jamais == pour comprer des chaînes, pourquoi ? exemple String hel="Hel"; if (hel=="Hel") me renvoie un true if (hel.substring(0,3)=="Hel") me renvoie aussi un true alors que selon mon livre ça devrait me renvoyer un résultat probablement faux
Pourriez-vous me donner des exemples de réprésentation d'unité de code et de point de code ?
Là tu es tombé dans un cas particulier, parce que tu compares à une chaîne constante, et comme il y a unicité des objets String, ça marche...
Mais essaie plutôt :
String hel = "Hel"; String hel2 = "Hel";
Et compare le résultat de : if (hel == hel2) et de : if (hel.equals(hel2))
Au passage, petit truc "classique", quand on compare une chaîne à une chaîne constante, il est préférable d'écrire :
if (CONSTANTE.equals(maChaine))
plutôt que : if(maChaine.equals(CONSTANTE))
car si par malheur maChaine est null, on évite la nullPointerException (a supposer que l'on soit bien certain que CONSTANTE ne sera pas null, mais a priori c'est normalement le cas...)
-- Christophe Franco
TestMan
Bonjour, Bonjour,
Dans un livre (au coeur de java) je lis N'employez jamais == pour comprer des chaînes, pourquoi ? exemple String hel="Hel"; if (hel=="Hel") me renvoie un true if (hel.substring(0,3)=="Hel") me renvoie aussi un true alors que selon mon livre ça devrait me renvoyer un résultat probablement faux
Regardez le code de la méthode substring pour java.lang.String et vous aurez une clarification sur ce point :)
Pourriez-vous me donner des exemples de réprésentation d'unité de code et de point de code ? Dans tout ce que je lis, il y a beaucoup d'explication pompeuse et aucun exemple. Je n'arrive pas à bien saisir la différence (pas de lien, des exemples svp :D)
L'opérateur == compare sur des types complexes (ici des "objets") compare la valeur de la référence et non le contenu de l'objet. En clair, == teste si les deux références pointent vers la même instance (le même objet).
Si vous voulez tester l'égalité, il faut utiliser la méthode o1.equals(o2)
Il existe des exceptions, mais pour débuter, vous pouvez les ignorer allègrement ...
A+ TM
Bonjour,
Bonjour,
Dans un livre (au coeur de java) je lis
N'employez jamais == pour comprer des chaînes, pourquoi ?
exemple
String hel="Hel";
if (hel=="Hel") me renvoie un true
if (hel.substring(0,3)=="Hel") me renvoie aussi un true alors que
selon mon livre ça devrait me renvoyer un résultat probablement faux
Regardez le code de la méthode substring pour java.lang.String et vous
aurez une clarification sur ce point :)
Pourriez-vous me donner des exemples de réprésentation d'unité de code
et de point de code ?
Dans tout ce que je lis, il y a beaucoup d'explication pompeuse et
aucun exemple. Je n'arrive pas à bien saisir la différence (pas de
lien, des exemples svp :D)
L'opérateur == compare sur des types complexes (ici des "objets")
compare la valeur de la référence et non le contenu de l'objet. En
clair, == teste si les deux références pointent vers la même instance
(le même objet).
Si vous voulez tester l'égalité, il faut utiliser la méthode o1.equals(o2)
Il existe des exceptions, mais pour débuter, vous pouvez les ignorer
allègrement ...
Dans un livre (au coeur de java) je lis N'employez jamais == pour comprer des chaînes, pourquoi ? exemple String hel="Hel"; if (hel=="Hel") me renvoie un true if (hel.substring(0,3)=="Hel") me renvoie aussi un true alors que selon mon livre ça devrait me renvoyer un résultat probablement faux
Regardez le code de la méthode substring pour java.lang.String et vous aurez une clarification sur ce point :)
Pourriez-vous me donner des exemples de réprésentation d'unité de code et de point de code ? Dans tout ce que je lis, il y a beaucoup d'explication pompeuse et aucun exemple. Je n'arrive pas à bien saisir la différence (pas de lien, des exemples svp :D)
L'opérateur == compare sur des types complexes (ici des "objets") compare la valeur de la référence et non le contenu de l'objet. En clair, == teste si les deux références pointent vers la même instance (le même objet).
Si vous voulez tester l'égalité, il faut utiliser la méthode o1.equals(o2)
Il existe des exceptions, mais pour débuter, vous pouvez les ignorer allègrement ...
A+ TM
Xavier Tarrago
Il me semble que String s1 = "Hel"; String s2 = "Hel"; s1 == s2 retourne true. En effet, il y a un mécanisme de partage des chaînes qui fait que les chaînes égales sont représentées par un même objet. Il faut faire String s3 = new String("Hel"); pour avoir un nouvel objet. s3 == s1 retourne alors faux. C'est pourquoi cette syntaxe new String("Hel") devrait être évitée comme c'est expliqué dans l'excellent "Java efficace" de Bloch.
En fait s1==s2 retourne vrai si les deux références pointent sur le même objet. s1.equals(s2) retourne vrai si les deux chaînes ont le même contenu. En fait, String étant immutable, on ne devrait jamais avoir s1.equals(s2) et s1!=s2 car cela veut dire que l'on a deux représentations de la même chaîne et qu'il y a gaspillage de mémoire. Par ailleurs l'implémentation de equals commence par tester s1==s2. Le gain de performance de == est donc faible, ce qui explique qu'on recommande de ne pas prendre le risque.
Enfin le livre ne devrait pas dire que (hel.substring(0,3)=="Hel") renvoie faux mais qu'il n'est pas garanti qu'il renvoie vrai. Cela dépend de l'implémentation de substring.
"Christophe Franco" a écrit dans le message de news: 1huxhni.k4iyr41djkjtxN%
xfredox wrote:
Dans un livre (au coeur de java) je lis N'employez jamais == pour comprer des chaînes, pourquoi ? exemple String hel="Hel"; if (hel=="Hel") me renvoie un true if (hel.substring(0,3)=="Hel") me renvoie aussi un true alors que selon mon livre ça devrait me renvoyer un résultat probablement faux
Pourriez-vous me donner des exemples de réprésentation d'unité de code et de point de code ?
Là tu es tombé dans un cas particulier, parce que tu compares à une chaîne constante, et comme il y a unicité des objets String, ça marche...
Mais essaie plutôt :
String hel = "Hel"; String hel2 = "Hel";
Et compare le résultat de : if (hel == hel2) et de : if (hel.equals(hel2))
Au passage, petit truc "classique", quand on compare une chaîne à une chaîne constante, il est préférable d'écrire :
if (CONSTANTE.equals(maChaine))
plutôt que : if(maChaine.equals(CONSTANTE))
car si par malheur maChaine est null, on évite la nullPointerException (a supposer que l'on soit bien certain que CONSTANTE ne sera pas null, mais a priori c'est normalement le cas...)
-- Christophe Franco
Il me semble que
String s1 = "Hel";
String s2 = "Hel";
s1 == s2 retourne true. En effet, il y a un mécanisme de partage des chaînes
qui fait que les chaînes égales sont représentées par un même objet. Il faut
faire
String s3 = new String("Hel"); pour avoir un nouvel objet.
s3 == s1 retourne alors faux. C'est pourquoi cette syntaxe new String("Hel")
devrait être évitée comme c'est expliqué dans l'excellent "Java efficace" de
Bloch.
En fait s1==s2 retourne vrai si les deux références pointent sur le même
objet.
s1.equals(s2) retourne vrai si les deux chaînes ont le même contenu.
En fait, String étant immutable, on ne devrait jamais avoir s1.equals(s2) et
s1!=s2 car cela veut dire que l'on a deux représentations de la même chaîne
et qu'il y a gaspillage de mémoire.
Par ailleurs l'implémentation de equals commence par tester s1==s2. Le gain
de performance de == est donc faible, ce qui explique qu'on recommande de ne
pas prendre le risque.
Enfin le livre ne devrait pas dire que (hel.substring(0,3)=="Hel") renvoie
faux mais qu'il n'est pas garanti qu'il renvoie vrai. Cela dépend de
l'implémentation de substring.
"Christophe Franco" <cfranco@pobox.com> a écrit dans le message de news:
1huxhni.k4iyr41djkjtxN%cfranco@pobox.com...
xfredox <xfredox@free.fr> wrote:
Dans un livre (au coeur de java) je lis
N'employez jamais == pour comprer des chaînes, pourquoi ?
exemple
String hel="Hel";
if (hel=="Hel") me renvoie un true
if (hel.substring(0,3)=="Hel") me renvoie aussi un true alors que
selon mon livre ça devrait me renvoyer un résultat probablement faux
Pourriez-vous me donner des exemples de réprésentation d'unité de code
et de point de code ?
Là tu es tombé dans un cas particulier, parce que tu compares à une
chaîne constante, et comme il y a unicité des objets String, ça
marche...
Mais essaie plutôt :
String hel = "Hel";
String hel2 = "Hel";
Et compare le résultat de :
if (hel == hel2)
et de :
if (hel.equals(hel2))
Au passage, petit truc "classique", quand on compare une chaîne à une
chaîne constante, il est préférable d'écrire :
if (CONSTANTE.equals(maChaine))
plutôt que :
if(maChaine.equals(CONSTANTE))
car si par malheur maChaine est null, on évite la nullPointerException
(a supposer que l'on soit bien certain que CONSTANTE ne sera pas null,
mais a priori c'est normalement le cas...)
Il me semble que String s1 = "Hel"; String s2 = "Hel"; s1 == s2 retourne true. En effet, il y a un mécanisme de partage des chaînes qui fait que les chaînes égales sont représentées par un même objet. Il faut faire String s3 = new String("Hel"); pour avoir un nouvel objet. s3 == s1 retourne alors faux. C'est pourquoi cette syntaxe new String("Hel") devrait être évitée comme c'est expliqué dans l'excellent "Java efficace" de Bloch.
En fait s1==s2 retourne vrai si les deux références pointent sur le même objet. s1.equals(s2) retourne vrai si les deux chaînes ont le même contenu. En fait, String étant immutable, on ne devrait jamais avoir s1.equals(s2) et s1!=s2 car cela veut dire que l'on a deux représentations de la même chaîne et qu'il y a gaspillage de mémoire. Par ailleurs l'implémentation de equals commence par tester s1==s2. Le gain de performance de == est donc faible, ce qui explique qu'on recommande de ne pas prendre le risque.
Enfin le livre ne devrait pas dire que (hel.substring(0,3)=="Hel") renvoie faux mais qu'il n'est pas garanti qu'il renvoie vrai. Cela dépend de l'implémentation de substring.
"Christophe Franco" a écrit dans le message de news: 1huxhni.k4iyr41djkjtxN%
xfredox wrote:
Dans un livre (au coeur de java) je lis N'employez jamais == pour comprer des chaînes, pourquoi ? exemple String hel="Hel"; if (hel=="Hel") me renvoie un true if (hel.substring(0,3)=="Hel") me renvoie aussi un true alors que selon mon livre ça devrait me renvoyer un résultat probablement faux
Pourriez-vous me donner des exemples de réprésentation d'unité de code et de point de code ?
Là tu es tombé dans un cas particulier, parce que tu compares à une chaîne constante, et comme il y a unicité des objets String, ça marche...
Mais essaie plutôt :
String hel = "Hel"; String hel2 = "Hel";
Et compare le résultat de : if (hel == hel2) et de : if (hel.equals(hel2))
Au passage, petit truc "classique", quand on compare une chaîne à une chaîne constante, il est préférable d'écrire :
if (CONSTANTE.equals(maChaine))
plutôt que : if(maChaine.equals(CONSTANTE))
car si par malheur maChaine est null, on évite la nullPointerException (a supposer que l'on soit bien certain que CONSTANTE ne sera pas null, mais a priori c'est normalement le cas...)
-- Christophe Franco
remy
en gros et pour faire simple un seul fichier Main.java