Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Questions de débutant

5 réponses
Avatar
xfredox
Bonjour,

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)

Merci d'avance chez zamis informaticiens ;)

5 réponses

Avatar
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

Avatar
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

Avatar
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



Avatar
remy

en gros et pour faire simple un seul fichier Main.java

public class Main {

public static void main(String[] args) {
Essai e=new Essai();
}
}

class Essai
{
Type s,s1;
Essai()
{
try {
s=new Type("essai");
s1 = (Type)s.clone();

System.out.println("s.a ="+s.a);

if(s==getType())System.out.println("pipo ok");

System.out.println("s.a ="+s.a);

if(s==s1){
System.out.println("pipo ok 2");
}else
{
System.out.println("s != s1");
}
} catch (CloneNotSupportedException e) {System.out.println(e);}

}
public Type getType(){s.a="pipo";return s;}
}

class Type implements Cloneable {
String a;

public Type(String c ) {
a = c;
}
public Object clone() throws CloneNotSupportedException {
return super.clone();
}
}

s.a =essai
pipo ok
s.a =pipo
s != s1

a+ remy
Avatar
xfredox
Merci pour toutes vos réponses, c'est très clair maintenant !
A bientôt pour de nouvelles aventures javanesques