Hashcode

[b1zarRe]

Hallo,

wir sind heute in der Vorlesung das Thema "Hashcodes" durchgegangen sowie allgemein die Klasse Object.
Die Methoden, welche man überschreiben kann(wie toString(), equals(), etc.) habe ich direkt verstanden... jedoch verstehe ich jetzt in der Nachbereitung nicht, was es genau mit dem Hashcode auf sich hat...

So wie ich es verstanden habe, und bisher recherchiert habe, ist das eine Methode, welche man für seine "eigenen" Klassen überschreiben kann, um denen quasi eine Art EINDEUTIGE Identifikationsnummer zu verleihen. Stimmt dies?

Beispielsweise

public class Buch {
(...)
@Override
public int hashCode() {
  return this.titel+this.autor+this.erscheinungsjahr+this.preis;
//oder einfacher: return this.isbnNummer;
(...)
}
}

Ist das soweit korrekt? Was genau bringt "mir" das aber nun??? Macht man das um
bei x beliebig vielen Instanzen eindeutig eine Instanz von einer anderen unterscheiden zu können???
(Da ja dieser hashcode meines Wissens von "Java" durch die Überschreibung als Zahl generiert wird, und wenn zb. mit toString() versucht wird auf eine nicht überschriebene hashCode() instanz zuzugreifen, dann sieht man auch diesen Hashcode...)

Mir ist halt leider noch nicht klar, welchen praktischen Zweck dieses erfüllt???

 

[timbeau]

Naja, this.titel wird wohl kein int liefern insofern wird es einen Compilerfehler geben.

Aber hashCode wird aufgerufen um zu gucken ob Elemente gleich sind

 

[AlexSpritze]

Es ist nicht unbedingt eine eindeutige Identifikationsnummer. Es kann sein, dass du zwei Objekte hast, die den gleichen HashCode haben, aber nicht gleich sind.

Wenn ihr in der Vorlesung Datenstrukturen, wie die HashMap drannehmt, dann wird dir der Nutzen klarer. Über den hashCode kann damit nämlich schnell auf eine Menge von Elementen zugreifen.

Hashcode könntest du vergleichen mit Prüfsummen von Dateien, mit denen festgestellt werden kann, ob der Inhalt sich verändert hat.

 

[Spacerat]

Lass dich zerpflücken :lol: (musste ich auch schon über mich ergehen lassen, biss der Groschen fiel...)

Hashcodes werden in HashSets, HashMaps und HashTables verwendet. Sie dienen dazu, Objekte anhand ihres Inhaltes vor zu sortieren um schnelleren Zugriff zu gestatten. Eine eindeutige ID hat jedes Objekt von Haus aus - die Adresse in der es im Speicher liegt, in C++-Kreisen Referenz genannt -, dafür braucht es keinen Hashcode. Die Konventionen für Hashcode sind einfach. Objekte, die inhaltlich gleich sind sollten den gleichen Hashcode haben. Objekte die den gleichen Hashcode haben, müssen nicht zwangsläufig den gleichen Inhalt haben. Bestes Beispiel: Bilder - Für einen Hashcode hat man nur 32 Bits zur Verfügung, selten aber hat ein Bild blos 32 Bits vom Inhalt her.
Grundsätzlich gilt, dass wenn man "equals()" überschreibt, auch "hashCode()" überschreiben sollte. Wenn man nun so tut, sollte man alle Vergleichsdaten, die man in "equals()" verwendet, auch in die Berechnung des Hashcodes mit einbeziehen.
Generell haben alle Objekte bereits einen Hashcode, nämlich oben besagte Speicheradresse. Diese bekommt man im Prinzip auch von jedem Object zurück geliefert, wenn man "hashCode()" nicht überschreibt. Object selber implementiert "equals()" dann so:

 public boolean equals(Object o) {
  return (this == o);
}

Daraus folgt: Identische Objekte sind definitiv inhaltlich gleich! Nicht identische Objekte dagegen können inhaltlich gleich sein, müssen es aber nicht.

 

[Marco13]

Nebenbei: An die ""Speicheradresse"" (es ist nicht wirklich eine!) kommt man mit System.identityHashCode(object);

 

[b1zarRe]

Also, ich versuchs nochmal in eigenen Worten:

EIn HashCode ist also dazu da, um in Zurodnungen wie HashMap, oder Mengen wie HashSet zum Beispiel
vorzusortieren???
Ist das der einzige Grund warum man dies dann überschreibt?! Ist der Zugriff bzw. das Sortieren oÄ dadurch
soviel schneller oder anders: MUSS man hashcode überschreiben, wenn man Hashmap oÄ benutzt? //Verwirrung :/

Wäre sehr sehr nett, wenn jemand das anhand eines (Quellcode)Beispiels erläutern könnte... - welche
Vorteile es bringt, bzw warum man es machen muss... Stehe bei dem Thema auf dem Schlauch und muss
leider die Klausur wiederholen(erst in paar Monaten; aber frühes lernen schadet ja nicht ) und will
alles drauf haben.

 

[Spacerat]

Als Quellcodebeispiele kannst du dir entsprechende Implementationen in der API des JDKs ansehen (src.zip im JDK-Verzeichnis), z.B. die Wrapper-Klassen, Integer, Float, Double usw oder gar String.
Möglicherweise erschliessen sich ja auch noch andere Anwendungsgebiete, aber in Java-Standard sind die Hash-Klassen die geläufigsten.
In diesen Klassen werden Zwecks Zugriffsbeschleunigung sog. Hashgruppen angelegt in welche verschiedene Objektinstanzen mit verschiedenen Inhalten abgelegt werden. Im günstigsten Fall ist jede Gruppe einmal belegt, also auch die Hashcodes der Objekte verschieden. Die Berechnung eines Hashcodes geht in der Regel schneller, als 2 Objekte per "equals()" miteinander zu vergleichen. Das beschleunigt natürlich auch eine Hashklasse. Diese suchen halt erst per "hashCode()" und erst wenn eine Gruppe mehrfach belegt ist, per "equals()". Eine HashMap, welche KeyObjekte hat die allesammt eine Hashcode von meinetwegen 10 zurückgeben ist das langsamste, was man sich vorstellen kann. Je nachdem, wie gut "hashCode()" und "equals()" implementiert sind, desto weniger bringt man die Hashklassen aus dem Tritt. Man kann es aber auch übertreiben: IdentityHashMap ist dafür ein Beispiel - von den Hashklassen die schnellste, vergleicht aber nur per Identität (==), was nicht überschriebenen "hashCode()"- und "equals()"-Methoden entspräche.
Um es kurz zu machen: Ja, wenn du deine Objekte vernünftig in Hashklassen (bei Maps gilt das nur für den Key) verwenden willst, solltest du "hashCode()" und "equals()" überschreiben.

 

[tuttle64]

Kleine Ergänzung: sofern Wrapper-Klassen (z.B. String, Integer) als Key verwendet werden, muss der hashCode nicht mehr überschrieben werden, da diese Klassen diesen bereits überschreiben. Zudem geht es beim hashCode nicht nur um die Performance, sondern darum, dass man die Objekte in der Collection überhaupt wieder findet.

 

[Spacerat]

Kleine Ergänzung: sofern Wrapper-Klassen (z.B. String, Integer) als Key verwendet werden, muss der hashCode nicht mehr überschrieben werden, da diese Klassen diesen bereits überschreiben.

...und als weitere Ergänzung, die Tatsache, dass man das auch kar nicht kann, weil diese Klassen final sind...
Dachte das wüsste man. Deswegen hab' ich's nicht erwähnt. Kamen nur als Beispiele für Quellcodes, weil ich wusste, dass diese das vernünftig implementieren.

 

[Crian]

Ich hab dir mal ein Beispiel gebastelt, die Methoden hab ich dabei einfach von Eclipse erzeugen lassen.

package forumProblems;

public class Book {
    private String title;
    private String author;
    private String year;
    private int priceInCent;

    public Book(String title, String author, String year, int priceInCent) {
        this.title = title;
        this.author = author;
        this.year = year;
        this.priceInCent = priceInCent;
    }


    public String getTitle() {
        return title;
    }


    public String getAuthor() {
        return author;
    }


    public String getYear() {
        return year;
    }


    public int getPriceInCent() {
        return priceInCent;
    }


    @Override
    public String toString() {
        return "Book [title=" + title + ", author=" + author + ", year=" + year
                + ", priceInCent=" + priceInCent + "]";
    }


    @Override
    public int hashCode() {
        final int prime = 31;
        int result = 1;
        result = prime * result + ((author == null) ? 0 : author.hashCode());
        result = prime * result + priceInCent;
        result = prime * result + ((title == null) ? 0 : title.hashCode());
        result = prime * result + ((year == null) ? 0 : year.hashCode());
        return result;
    }


    @Override
    public boolean equals(Object obj) {
        if (this == obj)
            return true;
        if (obj == null)
            return false;
        if (getClass() != obj.getClass())
            return false;
        Book other = (Book) obj;
        if (author == null) {
            if (other.author != null)
                return false;
        }
        else if (!author.equals(other.author))
            return false;
        if (priceInCent != other.priceInCent)
            return false;
        if (title == null) {
            if (other.title != null)
                return false;
        }
        else if (!title.equals(other.title))
            return false;
        if (year == null) {
            if (other.year != null)
                return false;
        }
        else if (!year.equals(other.year))
            return false;
        return true;
    }


    public static void main(String[] args) {
        Book b1 = new Book("Der kleine Hobbit", "J.R.R. Tolkien", "1957", 990);
        Book b2 = new Book("Der kleine Hobbit", "John Ronald Reuel Tolkien", "1957", 990);
        Book b3 = b1;

        System.out.println("Buch 1:\n\t" + b1);
        System.out.println("\t" + b1.hashCode());

        System.out.println("Buch 2:\n\t" + b1);
        System.out.println("\t" + b2.hashCode());

        System.out.println("Buch 3:\n\t" + b1);
        System.out.println("\t" + b3.hashCode());

        if (b1.equals(b2)) {
            System.out.println("Buch 1 == Buch 2 (via equals)");
        }
        else {
            System.out.println("Buch 1 != Buch 2 (via equals)");
        }

        if (b1.equals(b3)) {
            System.out.println("Buch 1 == Buch 3 (via equals)");
        }
        else {
            System.out.println("Buch 1 != Buch 3 (via equals)");
        }
    }

}

Ausgabe:

Buch 1:
	Book [title=Der kleine Hobbit, author=J.R.R. Tolkien, year=1957, priceInCent=990]
	-1501343730
Buch 2:
	Book [title=Der kleine Hobbit, author=J.R.R. Tolkien, year=1957, priceInCent=990]
	1514853508
Buch 3:
	Book [title=Der kleine Hobbit, author=J.R.R. Tolkien, year=1957, priceInCent=990]
	-1501343730
Buch 1 != Buch 2 (via equals)
Buch 1 == Buch 3 (via equals)

Nun könnte man das vielleicht ändern wollen, dass Buch 1 und 2 das "gleiche" sind. Oder auch nicht.

 

[bobbsen]

Nur mal so als kleine Anmerkung:

        System.out.println("Buch 1:\n\t" + b1);
        System.out.println("\t" + b1.hashCode());
 
        System.out.println("Buch 2:\n\t" + b1);
        System.out.println("\t" + b2.hashCode());
 
        System.out.println("Buch 3:\n\t" + b1);
        System.out.println("\t" + b3.hashCode());

hashCode() rufst du zwar auf allen 3 Objekten auf, deine toString() landet aber immer im Objekt b1. Könnte also verwirrend werden

(oder ich habs nicht richtig verstanden und es war Absicht *müde*)

 

[Crian]

oh stimmt, copy + paste *schmunzelt*

Das sollte sich ja leicht beheben lassen.

 

[b1zarRe]

Ich danke euch schonmal...
Also habe die Tage nochmal durch Skript geblättert und vieles was Spacerat geschrieben hat lies sich da auch finden,
in kurz:

1. Wenn a gleich(im Sinne von equals) b ist, dann muss auch der Hashcode von a und b gleich sein. Daraus folgt, dass man, wenn man equals überschreibt, auch hashcode überschreiben soll mit Einbezug der in Equals vorkommenden Eigenschaften/Variablen
und dieser Hashcode gleich sein.

2. Es kann sein, dass ein das zwei Objekte nicht gleich sind, aber den gleichen Hashcode haben.

3. Equals() überschreibung ist notwendig, um zu definieren, wann 2 Objekte gleich sind

4. HashCode() ist wichtig.... -> "das erfahren sie wenn wir hashmaps/hashsets etc. anschauen"

Also soweit ist bis auf Punkt 2 und 4 alles klar... Wann kann denn der Hashcode zweier Objekte gleich sein, aber gleichzeitig die Typen nicht gleich... auch Punkt 4. nervt mich... weil ich es im moment einfahc nur mache, aber nicht wirklich verstehe,
wozu ich hashcode brauche(ausser diesen Punkt, der hier angesprochen wurde: Schnellere (Vor)Sortierung - ist das alles?)

Ich danke euch.

 

[Marco13]

"Sortierung" nicht - nur "die Stelle finden, wo das Objekt steht". Wird schon noch drankommen ... oder hilft Hashtabelle ? Wikipedia nicht schon weiter?

 

[Spacerat]

ausser diesen Punkt, der hier angesprochen wurde: Schnellere (Vor)Sortierung - ist das alles?

Jep, das ist alles.
Zu Punkt 2: Das kann vorkommen. Sollte es aber nur bei Instanzen unterschiedlichen Typs (Klasse). Stellen wir uns mal vor, wir haben Integer.MAX_VALUE * 2 unterschiedliche Integer und ebenso viele unterschiedliche Floats. Da müssen die Hashcodes bereits zwangsläufig paarweise auftauchen.
Zu Punkt 4: Es ist wichtig, dass man sich bewusst macht, dass wenn man [c]equals()[/c] überschreibt, auch [c]hashCode()[/c] überschreibt, weil man sonst Hash-Datenstrukturen aus dem Tritt bringen würde.

Ich hab' dir mal den Link rausgesucht, wo sie mich "durchgemangelt" haben. Wenn ich's heute les... OMG. :lol:
@Marco13: Also "Vorsortieren" bzw. an einer Stelle (Hashgruppe) ablegen, wo man sie schneller wiederfindet. Okay... "Vorsortieren" ist vllt. schlecht gewählt, aber mach' nen besseren Vorschlag.

 

[b1zarRe]

Ich hab' dir mal den Link rausgesucht, wo sie mich "durchgemangelt" haben. Wenn ich's heute les... OMG.

Schick mir den bitte auch

 

[Spacerat]

Link
Tja, wenn man einen Link raussucht, sollte man ihn auch einfügen.

 

[b1zarRe]

Also ich denke ich habe es vorerst verstanden, hier in kurz:

1. Equals() dient dazu zu definieren, wann zwei Objekte gleich sind, falls equals nicht überschrieben wird, dann verweist das equals() aus der Klasse Object auf die Speicheradresse und dadurch werden zwei Objekte, welche auf equals geprüft werden false.
Es sollte also so überschrieben werden, dass die "Kernelemente" des jeweiligen Objektes true liefert, wenn diese gleich sind.
Auch geht hervor, dass ein Objekt auf sich selbst equals true liefern muss(reflexiv), sowie das wenn a=b ist und b=c das auch a=c sein muss(transitiv) sowie das die equals Ausgabe konsistent sein muss(Sprich: es darf nicht einmal true sein... und irgendwann später(ohne Grund) false)

2. Falls Equals true liefert, müssen die beiden zu vergleichenden Objekte den gleichen Hashcode(sprich: Hashcode muss überschrieben werden) besitzen, welcher auch aus den Kernelementen zusammengesetzt ist und welcher dazu dient eine Art Vorsortieren für schnellere Collectionszugriff zu gewährleisten. Es kann aber sehr wohl sein, dass 2 Objekte den gleichen Hashcode besitzen, aber NICHT gleich sind.(<- KORREKT?)

Beispiel:

public class Spielergebnis {
    private String links;
    private String rechts;
    private final char TRENNER = ':';
    
    public Spielergebnis(String links, String rechts) {
        this.links = links;
        this.rechts = rechts;
    }
    
    @Override
    public String toString() {
        return links + TRENNER + rechts;
    }
    
    @Override
    public boolean equals(Object obj) {
        boolean wert = false;
        
        if(obj instanceof Spielergebnis) {
            Spielergebnis spielergebnis = (Spielergebnis) obj;
            if(((this.links.equals(spielergebnis.links) && this.rechts.equals(spielergebnis.rechts))
                    || (this.links.equals(spielergebnis.rechts) && this.rechts.equals(spielergebnis.links)))) {
                wert = true;
            }
        }
        return wert;
    }
    
    @Override
    public int hashCode() {
        return links.hashCode() + rechts.hashCode();
    }
    
    public static void main(String[] args) {
        
        /* Test */
        Spielergebnis sp1 = new Spielergebnis("2","1");
        Spielergebnis sp2 = new Spielergebnis("2", "1");
        System.out.println(sp1.equals(sp2)); // True bei 2:1 oder 1:2
        System.out.println(sp1.hashCode());
        System.out.println(sp2.hashCode()); // Bei True gleicher hashcode!
    }
}

=> Ich wollte eine Klasse realisieren, die einen Spielstand wie 1:2 GLEICHWERTIG zu 2:1 setzt.
Sprich: 1:2 ist das gleiche wie 1:2 sowie 2:1. Dieses Beispiel hat evtl. nur wenig Sinn... aber war mal eine Klausuraufgabe

Wäre nett, wenn ihr Kritik dazu äußern könnte, ob alles stimmig ist.... UUUuuund wann ein Fall: Gleicher Hashcode, aber equals false eintreten könnte.

 

[Spacerat]

Die Sache mit der "Speicheradresse" gehört in Anführungszeichen, denn wie Marco13 schon erwähnt hat, es ist nicht wirklich eine (sie wird nur zur Berechnung des Identität-Hashcodes herangezogen, weil sich halt keine zwei verschiedenen Objekte die selbe Adresse teilen können).
Ferner gibt es zwei Arten von gleich (ACHTUNG! Das Selbe ist nicht das Gleiche. Ich kann mir aber leider auch nie merken, was was ist), inhaltliche Gleichheit und Identität. Inhaltliche Gleichheit wird mit [c]equals()[/c] festgestellt und Identität mit [c]==[/c] (Plötzlich kann man sich doch merken, was was ist -> Identitätsprüfung liefert [c]true[/c] wenn auf beiden Seiten des Vergleichs ein und das selbe Objekt steht). Logischerweise sind identische Objekte folgerichtig auf jeden Fall inhaltlich gleich.
Zu deinem Spielstand: (also ich denke mal, dein Anfall zu glauben, das es Sinn macht, den Spielstand in equals auch umdrehen zu dürfen, ist nur kurzfristig, man wird sehen)

public class Spielergebnis
{
  private static String TRENNER = ":";

  private final int links, rechts; // "private final" markiert Objekt als immutable
  private final String out;

  public SpielErgebnis(int links, int rechts)
  {
    this.links = links;
    this.rechts = rechts;
    out = links + TRENNER + rechts;
  }

  public String toString()
  {
    return out;
  }

  public int hashCode()
  {
    return links + rechts;
  }

  public boolean equals(Object obj)
  {
    if(this == obj) {
      return true;
    }
    if(obj instanceof Spielergebnis) {
      Spielergebnis se = (Spielergebnis) obj;
      return (se.links == links && se.rechts == rechts) || (se.links == rechts && se.rechts == links);
    }
    return false;
  }
}

Gleicher Hash aber inhaltlich verschieden sollte nur bei unterschiedlichen Klassen vorkommen. Ist aber mehr zufällig, wenn das vorkommt.

 

[HimBromBeere]

Ich kann mir aber leider auch nie merken, was was ist

[OT]Die selbe Entität mit gleichem Inhalt
Also das Selbe ist identitätsgleich, das Gleiche inhaltsgleich...[/OT]

 

[b1zarRe]

Dickes Danke @ Spacerat und Andere!!!

Zum Merken: ich merke es mir gedanklich: Irgendwer könnte ein gleiches Auto wie ich fahren... aber es wird nicht dasselbe sein...(ausser er zieht es mir ab ).

(Denke) letzte Frage: Wenn man mit equals auf Gleichheit testet(->inhalt)/bzw. mit der equals() Überschreibung testet wann etwas gleich ist und mit == auf Identität, warum benutzt man überhaupt == bei Objekten?

Ich meine klar 3==3 liefert true okay... so habe ich es gelernt bei primitiven Typen, aber bei Objekten immer mit
equals(). Wozu also bei Objekten also == anwenden... etwa um im Fluss des Programmierens schnell herauszufinden ob es eine Instanz ist oder anderes Objekt oder ob es das Objekt ist, mit dem man gerade was macht? Der Sinn dahinter wird mir leider nicht klar.

 

[schalentier]

(Denke) letzte Frage: Wenn man mit equals auf Gleichheit testet(->inhalt)/bzw. mit der equals() Überschreibung testet wann etwas gleich ist und mit == auf Identität, warum benutzt man überhaupt == bei Objekten?

Ich meine klar 3==3 liefert true okay... so habe ich es gelernt bei primitiven Typen, aber bei Objekten immer mit
equals(). Wozu also bei Objekten also == anwenden... etwa um im Fluss des Programmierens schnell herauszufinden ob es eine Instanz ist oder anderes Objekt oder ob es das Objekt ist, mit dem man gerade was macht? Der Sinn dahinter wird mir leider nicht klar.

Weil es Java ist ;-)

'==' vergleicht IMMER die Objektidentitaet, also nimmt die bereits angesprochenen "Speicheradressen" zum vergleichen. Voellig egal, ob du equals ueberschrieben hast, oder nicht. Daraus ergeben sich (leider) ein paar komische Effekte (z.B. "Hallo" == "Hallo" ist NICHT true). Einfach weil die beiden Strings zweimal im Speicher rumliegen und damit zwei unterschiedliche Adressen haben.

Bei primitiven Typen gibt es keine equals Methode, weil primitive Typen keine richtigen Objekte sind (1.equals(2) geht nicht).

Es gibt Faelle, wo es sinnvoll sein kann, auch bei Objekten mittels '==' zu vergleichen. Der groesste Vorteil ist, dass ein solcher Vergleich sehr viel schneller sein kann, als ein equals Aufruf. Allerdings muss man dann irgendwie sicherstellen, dass es niemals zwei Objekte an zwei Adressen gibt, die den gleichen Inhalt haben (also equals true liefert).

Am besten erstmal einfach immer dran halten: Bei Primitiven Typen IMMER ==, bei allen andren IMMER equals.

In anderen Sprachen kann man uebrigens '==' ueberschreiben, so kann man diese Verwirrung etwas entwirren - erhaelt aber an anderen Stellen evtl. noch viel verwirrendere Effekt ;-)

 

[fastjack]

Lies dir die Api durch, besonders die von Object. Da wird ganz genau erklärt was hashCode() und equals() machen. Übrigens sollte man die Methoden nicht nur überschrieben, sondern muß es eigentlich. Es gibt nix schlechteres, als mit einer Api zu arbeiten, deren Objekte weder hashCode() noch equals() überschreiben, oder vielleicht nur eins von beiden Übrigens kann man dabei auch gleich toString() überschreiben.

 

[Spacerat]

Am besten erstmal einfach immer dran halten: Bei Primitiven Typen IMMER ==, bei allen andren IMMER equals.

Autsch...
Wenn ich euch jetzt meine Lösung für mein damaliges Problem liefere, kann man diese Aussage at Acta legen, denn "==" auf Objekte macht durchaus Sinn, nämlich dann, wenn in einer Collection der Inhalt zweier Objekte ruhig gleich sein darf, diese Collection jedoch keine zwei identischen Objekte haben soll - IdentityList oder IdentitySet. Nur weil man solche Collections nicht unter [c]java.util[/c] findet, bedeutet das nicht, das sie keinen Sinn machen, denn das tun sie (Eine entsprechende Map gibt's ja auch). Versucht mal mit 'nem TreeSet Telefonbucheinträge per Vornamen zu sortieren. Inhaltlich gleiche Vornamen werden von dieser Collection nämlich verschluckt, so dass am Ende z.B. nur ein "Horst" im gesamten Telefonbuch überbleibt. Ok, ist ein schlechtes Beispiel; Telefonbucheinräge sortiert man natürlich per Comparator (Suchindex) und hält sie komplett im Set. Aber immerhin... es gibt per Definition keine zwei inhaltlich gleichen Objekte in einem Set. Also halten wir uns doch in Zukunft lieber immer daran, stets genau zu wissen, was man tut, satt immer irgendwelche allgemein gültigen Grundsätze herunter zu beten.
[ot]Passend zu equals() hier noch der kleine Beweis, dass "true" auch mal "false" sein kann. Geht natürlich nur in PHP und vergleichbaren Sprachen, wo man es mit Typsicherheit nicht allzu genau nimmt. Aber nehmt das blos nicht ernst.
PHP verwendet "==" zum Überprüfen der inhaltlichen Gleichheit und "===" für die Identität. In PHP werden Zahlen, Strings, primitive und andere Objekte intern automatisch gecastet, ein Integer 0 und ein String "0" wären also schonmal inhaltlich gleich (0 == "0" liefert true). Ein Leerstring und der Wert 0 werden gleichermassen auf false gecastet, beinhaltet ein String mindestens ein Zeichen wird er auf true gecastet (0 == false liefert true; "0" == true liefert true). Zusammengefasst liefert folgendes also nur grösste Verwirrung: [c]("0" == true) == (0 == false) == ("0" == 0)[/c] maw: true != true folglich: true == false...:lol:[/ot]

 

[schalentier]

@Spacerat: Ich hab mein Post grad nochmal gelesen und schlage vor, du liest ihn auch nochmal. Nichts anderes als du schrub ich ;-)

 

[Spacerat]

@Spacerat: Ich hab mein Post grad nochmal gelesen und schlage vor, du liest ihn auch nochmal. Nichts anderes als du schrub ich ;-)

Ähhh... du meintest vllt. "schrieb ich"?
Okay... Mich hatte nur dieses dicke IMMER angeschrien, meine Ohren klingen immer noch.