Verwendet Java Zeiger oder Referenzen? (Was für den Experten)

mngbd

~john schrieb:

Aber in vielen anderen Programmiersprachen gibt es ebenfalls keine Zeigerarithmetik und man nennt das Sprachkonstrukt trotzdem Zeiger.

Zum Beispiel?

NullPointerException vs. NullReferenceException

*john 0

Bashar schrieb:

~john schrieb:

Nein, Fortran folgt dieser Sprachregelung ebenfalls.

Ich rede von Referenztypen, nicht von call-by-reference. Erstere gibt es in Fortran meines Wissens nicht. In Pascal, was du auch genannt hattest, auf keinen Fall.

Ich rede ganz bewußt vom Konzept der Referenz, und das ist wie bereits beschrieben so alt wie Programmiersprachen nur sein könnten, und ja man kann in Fortran derselben Variablen verschiedene Namen verpassen, siehe EQUIVALENCE und COMMON. Auch wenn ich persönlich das Zeug als Hexengebräu bezeichne, und EQUIVALENCE das Analogon zu C unions ist. COMMON Blöcke (seit FORTRAN II dabei) erfüllen den Job einer Referenz, wenn man sie so eingesetzt hat. Beide Konstrukte sollte man in neuem Code nicht mehr verwenden.

Bashar

~john schrieb:

Ich rede ganz bewußt vom Konzept der Referenz

Es geht aber hier nicht um das Konzept sondern um das Wort.

robot

Leicht OT: Abgesehen davon, dass man es wahrscheinlich nicht braucht, könnte man eine Swap-Mehtode in Java mittels eines Wrapper-Objects realisieren (Java.lang.Integer kann man hier leider nicht nehmen, da diese Immutable ist)

class Test {

	public static void main(String[] args) {
		MutableInt a = new MutableInt(1);
		MutableInt b = new MutableInt(2);
		swap(a, b);
		a.swap(b); // oder als Obekt-Methode verwenden
		System.out.println("a=" + a + " b=" + b);
	}

	public static void swap(MutableInt a, MutableInt b) {
		MutableInt tmp = new MutableInt(a.value);
		a.value = b.value;
		b.value = tmp.value;
	}

	public static class MutableInt {
		public int value;
		public MutableInt(int value) {this.value = value;}
		public String toString() {return Integer.toString(value);}
		public void swap(MutableInt b) {int tmp = value; value = b.value; b.value = tmp;}
	}
}

Eine andere Möglichkeit wäre z.B. ein Array anstatt dem Wrapper-Object zu nehmen und Inhalte zu vertauschen.

Bashar schrieb:

~john schrieb:

Ich rede ganz bewußt vom Konzept der Referenz

Es geht aber hier nicht um das Konzept sondern um das Wort.

Das ist das Problem mit ~john, er redet immer am Thema vorbei.

als java rauskam wurde oft beworben das es "no memory leaks" und "no wild pointer" gibt, weil es keine pointer gibt.

ich denke die differenzierung ist 99% marketing, aber auch ein wenig wahr, denn auf "irgendwas" kann man nicht zeigen, es gibt immer ein objekt auf das verwiesen wird (das ist ja auch bei c++ references der fall, sofern man nicht von ptr references erstellt). null in java ist auch ein objekt.

Zeus

raps schrieb:

null in java ist auch ein objekt.

Sicher nicht. Null ist ein Wert der Referenz.

knivil

raps schrieb:

ich denke die differenzierung ist 99% marketing, aber auch ein wenig wahr, denn auf "irgendwas" kann man nicht zeigen, es gibt immer ein objekt auf das verwiesen wird (das ist ja auch bei c++ references der fall, sofern man nicht von ptr references erstellt). null in java ist auch ein objekt.

In C++ kann ich mittels new ein Objekt anlegen und mir eine Referenz darauf anlegen. Gebe ich jetzt das Objekt mittels delete frei, so "zeigt" die zugehoerige Referenz auf nichts. null ist in Java auch keine Objekt, da es sonst von Object erben wuerde und ich z.B. die Methode toString aufrufen koennte.

Nexus

Ich denke, raps hat insofern Recht, als es in Java keine Dangling Pointers gibt. Man kann zwar logisch unsinnige Referenzen haben und z.B. Objekte zu lange am Leben erhalten, aber ein Nicht-Null-Zeiger kann immer dereferenziert werden. Ob das nun ein wesentlicher Vorteil ist oder das "Kein Absturz -> funktioniert"-Prinzip fördert, ist eine andere Frage...

@robot: Das Problem ist, dass ein swap() in Java nicht gut in bestehende Dinge integrierbar ist. Man muss jeweils eine separate Wrapper-Klasse verwenden. Und da ist ein Inline-Dreieckstausch halt oft einfacher.