Java vs C++

Sgt. Nukem

Oh, mal wieder ein C++ vs. Java Thread!

voll katt schrieb:

Die Aufgabe ist nur für Gurus.

Ach Unsinn. Das ist eigentlich ganz harmlos. Man muss es nur können. Griffi kann das zum Beispiel und der behauptet nicht von sich, dass er'n Java-Guru ist.

Griffin

Griffi kann das zum Beispiel und der behauptet nicht von sich, dass er'n Java-Guru ist.

Ja, aber deine Aufgabe ist nicht wirklich schwer!

public static void main(String argsy[]) {
	   A a = new A(10);
	   try {
		   a.equals("");
	   } catch (Exception e) {
		   e.printStackTrace();
	   }
	   try {
		   a.equals(null);
	   } catch (Exception e) {
                     e.printStackTrace();
	   }
   }

@Java vs C++: Du willst metallicakeke wohl reinlegen, indem du nur auf die kleinen Bugs hinweist, heh?

Java ist schon gut, aber an C++ kommt es nicht annähernd ran.

hashCode überschreiben.

Gregor@Home schrieb:

Soso. Dein Wissen beruht also auf Hörensagen, heh? Aus meiner Sicht bestätigt das nur meine vorige Aussage. Du kannst die Aussagen deiner Bekannten selbst nicht einschätzen, sondern nur unreflektiert übernehmen. Du kannst ja nichtmal einschätzen, ob deine Bekannten wissen, über was sie da reden.

Und in 2 Monaten lernst du weder C++ noch Java. So eine Aussage wird auch nicht durch ein "" glaubwürdiger. Aber ich gebe dir Gelegenheit, zu zeigen, dass du zumindest Java beherrscht. Folgender Code enthält ein paar Bugs. Wenn du den Code derart korrigieren kannst, dass er bugfrei ist, dann nehme ich meine Aussage oben zurück und behaupte das Gegenteil. Dann nehme ich dir ab, dass du genug Überblick über die Sprache hast, um eine eigene Meinung diesbezüglich haben zu können, die auch begründet ist.
public class A extends B
{
   private final int a;
   
   public A (final int a)
   {
      this.a = a;
   }

   public boolean equals(Object o)
   {
      if (a == ((A)o).a) return true;
      return false;
   }

   public Object clone()
   {
      return new A(a);
   }
}
B ist hierbei eine Klasse, die das Cloneable Interface implementiert und einen parameterlosen Konstruktor anbietet.

public class A extends B
{
   public A ()
   {
      System.out.println("Java ist scheiße.");
   }
}

Jetzt sind alle Bugs beseitigt.

Bin nur Gelegenheits-(Java!!)Programmierer. Würde mich aber trotzdem
mal für die fachlich fundierte Musterlösung interessieren.
Ich glaub auf Antwort von metallicakeke wartest du vergeblich.

Redhead schrieb:

Bin nur Gelegenheits-(Java!!)Programmierer. Würde mich aber trotzdem
mal für die fachlich fundierte Musterlösung interessieren.
Ich glaub auf Antwort von metallicakeke wartest du vergeblich.

Ja, wahrscheinlich. ...und da ich im Chat eh schon jedem verraten habe, was die Problemstellen da sind, kann ich es hier ja auch machen. Ne Musterlösung werde ich jetzt aber nicht eintippen.

Also die wesentlichen Bugs beruhen hier darauf, dass die clone-Methode, die equals-Methode und die hashCode-Methode jeweils auf bestimmten nichtformalisierten Verträge beruhen, die in diesem Codestück nicht eingehalten wurden. Die einfachste Möglichkeit, sich darüber genauer zu informieren ist, in die API-Doku die Klasse Object genauer zu studieren. Da steht im Prinzip alles relevante drin. ...also wie sich diese Methoden zu verhalten haben, wie sie zu implementieren sind und so weiter.

Im Einzelnen ist das in etwa folgendes:

Das Objekt in der clone-Methode erzeugt man sich mit einem Aufruf von super.clone(). Wenn alle Superklassen clone richtig implementieren, kommt da am Schluss auch die richtige Klasse bei raus. ...weil da in er obersten Klasse ein bischen "Magie" stattfindet. Bei dem Objekt muss man dann möglicherweise noch ein paar Membervariablen richtig setzen. Insofern verträgt sich das eigentlich nicht mit finalen Membervariablen. ...hier aber anscheinend schon, wie ich vorhin gehört habe. ...muss das selbst nochmal ausprobieren.
Die equals-Methode soll natürlich keine RuntimeExceptions schmeißen, wie sie es hier tut. Darauf hat ja schon jemand hingewiesen. Außerdem soll die dadurch definierte Relation reflexiv, symmetrisch und transitiv sein. Das ist sie hier auch nicht. Ihr könnt euch ja mal überlegen, was hier zum Beispiel mit abgeleiteten Klassen und so geschieht. Wenn man null übergibt soll die equals-Methode im Übrigen false zurückliefern.
hashCode: Tritt hier ja gar nicht auf. ...aber es ist so, dass man hashCode immer überschreiben muss, wenn man equals überschreibt. Grund dafür ist, dass der Vertrag von hashCode vorsieht, dass die Methode für alle "gleichen" Objekte identische Werte liefert. Wenn das nicht gewährleistet ist, können solche Dinge wie Hashmaps und so nicht funktionieren.

Das sind alles so Sachen, die eigentlich zu den Basics gehören, die man aber ganz schnell in den Büchern überliest. Ich empfehle diesbezüglich das Buch "Effektiv Java programmieren". Da stehen eine ganze Menge Dinge in dieser Art drin.

Ich empfehle C++ und das Buch "Effektiv C++ programmieren".

cone schrieb:

Ich empfehle C++ und das Buch "Effektiv C++ programmieren".

Ah ja... ich empfehle bezüglich der Ursprungsfrage des Threaderstellers den ganzen Thread hier zu ignorieren und nur die allererste Antwort von Optimizer zu beachten.

http://www.c-plusplus.net/forum/viewtopic-var-p-is-954246.html#954246