Envoyez-le faire du C# alors.

Disons que le "==" peut se justifier dans certains cas, mais par expérience un DUT info n'a pas le niveau pour déterminer ces cas...

@Acné sauf que là ça ne se justifie absolument pas et que c'est une grossière erreur de compréhension. Un DUT info doit être capable de comprendre ça, faut pas déconner.

@Alex euh... tu es l'OP ? Tu connais le contexte ?

Donc je persiste et signe : dans certains cas on sait que les instances (donc les références) sont identiques (ou nulles) et que donc un "==" est préférable à un ".equals()". Mais il ne s'agit là que de cas très rares, et un DUT info (sans expérience) ne devrait pas se poser de question et utiliser systématiquement ".equals()" (avec une protection contre les nulls).

Sinon, je passe sur l'utilisation de ".intern()", des littéraux, des constantes, du "pool" de chaînes... Ce sont des cas avancés d'optimisations qui reposent sur "==".

Je connais pas le Java mais est-il possible qu'il ait fait une surcharge de l'opérateur "==" ?

(Me tuez pas, je demande pour ma propre information)

Quelqu'un pourrait il préciser la différence entre "==" et "equals" pour ceux qui ne font pas de Java?
Merci.

@Shirluban : en gros "==" compare les adresses en mémoire pour savoir si c'est la même instance de chaîne de caractères (et donc à fortiori égal caractère à caractère), et "equals" compare les caractères un à un.

@dyesdyes non, la surcharge d'opérateur n'existe pas en Java. Donc "==" fait comme pour tous les types de base : il compare les valeurs.

Mais alors, s'il compare les valeurs, il n'y a pas de problème ?

En fait, le point important est que "==" compare les valeurs des "types de base". Il compare donc les références (c.f. tauny). String étant un objet et non un type de base, "==" permet juste de vérifier s'il s'agit de la même instance d'objet.

D'un autre côté, dans Object (la classe racine de tous les objets) existe .equals(o) qui est surchargée pour comparer les contenus des objets.

Ayant fait un DUT Info, je confirme qu'on a vu la diffénce entre equals() et '=='.
C'est juste que le mec est borné.

Je ne connais pas encore java mais ne pas pouvoir utiliser l'opérateur de comparaison pour vérifier l'égalité du contenu est tout simplement absurde !
À quoi ont-ils pensé lors de la conception de ce langage ?

J'ai l'impression que ce type, comme moi, a étudié pendant deux ans le C et pendant 3 semaines le java.

@logical bien sûr que si on peut utiliser "==", c'est juste qu'il ne fait pas la même chose ! Savoir que l'on a deux références vers la même instance n'est pas la même chose que de savoir si on a deux instances dont les valeurs sont identiques.
Comme j'ai dit dans un précédent message, .equals(o) est défini au niveau de la classe Object dont tous les autres objets héritent. Ainsi, au sein de chaque classe, tu peux définir comment tester l'égalité entre deux instances en redéfinissant cette méthode.

@Acné : Troll. ^^ Et je ne suis pas tout à fait d'accord avec toi. Un DUT info peut tout à fait saisir la différence entre "==" et "equals", son diplôme ne signifie rien sur sa capacité d'abstraction/compréhension ... :)

@Bourriks: Ou pas.
En C aussi "==" compare les adresses de chaînes de caractères. (En C une string est un tableau de char, le nom de la string est en fait un pointeur vers le premier caractère.)
En C++ par contre, si on utilise une classe et la surcharge des opérateurs, "==" peut comparer le contenu de la string.


@logical: Ca se comprend pour certains langages qui ont peut de types de variables, genre le C: il n'y a pas de type "string", le compilateur voit uniquement un pointeur vers un tableau et il compare bien le contenu du pointeur: c-à-d l'adresse du tableau.

@Mary je n'ai jamais dit le contraire ! J'ai dit que, dans le cadre de mon expérience, il est préférable qu'un IUT info sans expérience utilise ".equals()". Je n'ai pas dit qu'il ne faisait pas la différence.

Par contre, j'apprécie le fait que tu commences ton message en signalant qu'il s'agit d'un troll.

@Acné : Oui oui mais c'est tout aussi valable pour un BTS ou un ingénieur, c'est tout ce que je veux dire ^^ Et je crois que je suis vraiment trop blonde en ce moment parce que je ne comprends pas ton "Par contre" ...

@Acné : Je pensais juste que le message de Bourriks était un troll, je ne parlais pas du mien :)

+1 pour @tauny

Et voilà pourquoi les créateurs du C# ont décidé que l'opérateur == sur les strings compare les valeurs...pas de code bizarre dans le genre. Au moins Java aura le mérite d'avoir servi de mauvais exemple...

@Acné "il est préférable qu'un IUT info sans expérience utilise ".equals()""
Ce n'est pas "préférable", c'est juste que ce n'est pas la même chose que == ! Incroyable quand même d'être aussi borné et de prendre les bac+2 pour des ahuris!

@Alex bah... ça fait juste 13 ans que j'encadre les nouveaux (entre autres) dans ma boîte... ma méthode est de les laisser faire sur leurs premiers codes, et quasi systématiquement les IUT tombent dans le panneau. En revanche, c'est le contraire avec les BTS. Par contre, avec les ingénieurs, c'est une chance sur deux.
Bon, je te laisse conclure, puisque je suis borné...

@Aethec bien sûr, Microsoft sait mieux que moi l'opération que je cherche à faire ! À force de miser tout sur l'apparence, le fond est pourri...

Ah tiens, pensait pas qu'il passerait (en même temps ça fait un bail que je l'ai postée).

Bref, oui, en DUT, on est censé apprendre la différence entre '==' et 'equals' (d'ailleurs, était (est toujours?) source d'énervement de mon ancien prof en IUT, bref).

Ce que je lui reproche finalement, c'est pas tant de ne pas avoir su sur le coup (bon, c'est quand même un truc important à savoir quand on fait du java, bien que je hais le java et préfère le C++), c'est plutôt le fait qu'il aie continué à être borné APRES lui avoir montré des sources. J'ai donc décidé de les laisser se débrouiller.

Suite du commentaire :

Acné => Je veux bien croire que ça puisse se justifier, encore faut-il se situer dans le contexte (et bien savoir la différence entre les deux, c'est clair), mais dans le contexte présent, ça n'avait aucun sens (En effet on pouvait instancier deux Strings différents de même contenu, désignant pourtant la même "entité").

Faut pas croire que tous les mecs sortant de DUT Info ne sont que des billes juste capable de cracher du code ^^.

@Acné : Dans 99% des cas, si tu veux comparer des strings, tu veux comparer leur valeur. Et la plupart du temps, si tu compare des strings par références, c'est une erreur et tu voulais en fait les comparer par valeur.
Autant faciliter le cas courant et rendre le cas peu courant et potentiellement erroné plus difficile à faire...
Dans le design d'un langage, rendre facile l'écriture de "bon" code est tout aussi important que de rendre difficile l'écriture de "mauvais" code.