Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1917 connectés 

 


Dernière réponse
Sujet : [Java] equals() = bizarre
darklord

- Renaud - a écrit a écrit :

 
 
Le dormeur vient de se reveiller!!!
 
En intercontrat?  




 
 
Consultant on the beach? J'ai connu ça aussi  :lol:


Votre réponse
Nom d'utilisateur    Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !
Le ton de votre message                        
                       
Votre réponse


[b][i][u][strike][spoiler][fixed][cpp][url][email][img][*]   
 
   [quote]
 

Options

 
Vous avez perdu votre mot de passe ?


Vue Rapide de la discussion
darklord

- Renaud - a écrit a écrit :

 
 
Le dormeur vient de se reveiller!!!
 
En intercontrat?  




 
 
Consultant on the beach? J'ai connu ça aussi  :lol:

- Renaud -

BifaceMcLeOD a écrit a écrit :

OK pour Ada plus blindé, mais pour C plus éprouvé, c'est à côté : le problème n'est pas le risque d'erreurs dans les compilateurs, mais dans le code applicatif lui-même, et de ce point de vue, Java est nettement moins risqué que C ou même C++.  




 
Le dormeur vient de se reveiller!!!
 
En intercontrat?

benou yes. rien vaut un bon système d'exception.
et pour ca, java et ada sont blindés !!
darklord

BifaceMcLeOD a écrit a écrit :

OK pour Ada plus blindé, mais pour C plus éprouvé, c'est à côté : le problème n'est pas le risque d'erreurs dans les compilateurs, mais dans le code applicatif lui-même, et de ce point de vue, Java est nettement moins risqué que C ou même C++.  




 
exactement!

BifaceMcLeOD OK pour Ada plus blindé, mais pour C plus éprouvé, c'est à côté : le problème n'est pas le risque d'erreurs dans les compilateurs, mais dans le code applicatif lui-même, et de ce point de vue, Java est nettement moins risqué que C ou même C++.
exo_ Au temps pour moi. Mais est-ce que Java est vraiment fréquemment utilisé pour coder des applications qui touchent à des domaines critiques ? Pour ma part, j'aurais plutôt imaginer que l'on utilisait des vieux machins éprouvés par le temps comme le C ou alors des trucs plus blindés comme Ada.
darklord

exo_ a écrit a écrit :

Ok ça vient de là :) En fait, j'avais essayé de la modifier mais j'avais mis hashcode() et non pas hashCode()... Alalala heureusement que personne ne programme des logiciels de gestion du trafic aérien en Java :)




 
D'où tiens tu cette information? Il y a des logiciels de gestion de traffic aérien en Java ... Chez EuroControl nottament ...

Gonzoide

exo_ a écrit a écrit :

Bon est-ce que quelqu'un a une idée pour associer un entier unique à une chaîne de caractère ? J'avais bien pensé à un truc du genre le code ascii de chaque caractère concaténé pour faire un nombre mais ça me parait super lourd comme méthode.  




 
Elle te plait pas, la methode hashCode par defaut de String ? Si tu veux en refaire une similaire, voila son algo:
 
Returns a hashcode for this string. The hashcode for a String object is computed as  
 
 s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]
 
using int arithmetic, where s[i] is the ith character of the string, n is the length of the string, and ^ indicates exponentiation. (The hash value of the empty string is zero.)

benou c'est la valeur de base. C'est ce que Object renvoie par défaut, parce qu'il ne sait pas quoi renvoyer d'autre ;)
 
C'est pour ca que dès que tu redéfinies equals, il faut redéfinir hashcode. Sinon ca marche plus ...
exo_ Ok ça marche si je renvoie le hashcode de ma chaîne. Mais en fait dans ma petite tête, je m'étais dit que : "Deux objets String distincts, même si ils ont la même valeur n'ont pas le même hashcode parce que le hashcode grosso modo c'est la valeur du pointeur (ou plutôt de l'identificateur) de l'instance." Mais apparemment ce n'est pas du tout le cas. Beaucoup merci en tout cas :)
benou

exo_ a écrit a écrit :

En fait, j'avais essayé de la modifier mais j'avais mis hashcode() et non pas hashCode()...  




 
y a un truc qui est dommage en Java, c'est que tu ne sois pas obligé de déclarer lorsque tu surcharge une méthode.
un truc du style  
 
public extending int hashcode () { ... }
 
Ca éviterait ce genre d'erreur difficilement visibles

benou t'as pas besoin de te faire chier avec ca !
la seule condition pour la méthode hashcode c'est qu'elle renvoie la même valeur pour  2 objets dans la méthode renvoie vrai.
 
Pour optimiser les algo de hashage (utiliser par les classes HashMap,etc ..), il faut essayer d'élargir le plus possible la plage de valeur que pourras renvoyer la méthode Hashcode.
 
Un truc tout simple, c'est de renvoyer la somme des hashcode des attributs dont tu teste l'égalité dans le equals. Mais attention, le hashcode peu finir par être assez gourmand avec cette méthode.
 
Tu peux par exemple de renvoyer que le hashcode de ta chaine de caractère. Ce sera nettement suffisant !
exo_ Ok ça vient de là :) En fait, j'avais essayé de la modifier mais j'avais mis hashcode() et non pas hashCode()... Alalala heureusement que personne ne programme des logiciels de gestion du trafic aérien en Java :)
 
Bon est-ce que quelqu'un a une idée pour associer un entier unique à une chaîne de caractère ? J'avais bien pensé à un truc du genre le code ascii de chaque caractère concaténé pour faire un nombre mais ça me parait super lourd comme méthode.
benou t'as redéfini le hashcode() ??
exo_ J'ai fait un petit programme de test pour vérifier que la méthode contains() d'un hashset fonctionne bien avec une classe que j'ai créé dans laquelle je redéfinis la méthode equals(). Eh bien, ça ne fonctionne pas et je ne comprends pas pourquoi.
 
Voilà le test :
 
class setUnicite {
 
    public static void main(String [] args) {
        Set s = new HashSet();
        String d = new String("toto" );
        Etat e1 = new Etat(d,true,false);
        Etat e2 = new Etat(d,true,false);
        Etat e3 = new Etat("toto",true,false);        
        s.add(e1);
        System.out.println("e1.equals(e1) = " + e1.equals(e1));        
        System.out.println("s.contains(e1) = " + s.contains(e1));
        System.out.println("e1.equals(e2) = " + e1.equals(e2));        
        System.out.println("s.contains(e2) = " + s.contains(e2));
        System.out.println("e1.equals(e3) = " + e1.equals(e3));        
        System.out.println("s.contains(e3) = " + s.contains(e3));
    }
     
}
 
Et voilà le résultat :
 
[root@localhost test]# java setUnicite
e1.equals(e1) = true
s.contains(e1) = true
e1.equals(e2) = true
s.contains(e2) = false
e1.equals(e3) = true
s.contains(e3) = false
 
Et pourtant là où ça devient magique, c'est quand on regarde la specif de contains() :  
 
Returns true if this set contains the specified element. More formally, returns true if and only if this set contains an element e such that (o==null ? e==null : o.equals(e)).
 
Alors si quelqu'un a une idée sur le phénomène, merci d'avance.

Copyright © 1997-2025 Groupe LDLC (Signaler un contenu illicite / Données personnelles)