Was genau habe ich von Pointern?

Simon2

Tachyon schrieb:

NixDa schrieb:

Tachyon schrieb:

NixDa schrieb:

Denn Zeiger hat ja fast jede Sprache: Java, C#, PHP, Python,...

Jo, das sind alles Sprachen mit Zeigern...

Ja sind sie, auch wenn sie es immer "Referenzen" nennen. Aber das ist Marketing-Blabla weil Zeiger ja böse sind...

Ne, das sind Referenzen.

.... und was sind dann "Zeiger" ?

... und was sind dann "C++-Referenzen" ?

Gruß,

Simon2.

Shade Of Mine

Tachyon schrieb:

Ne, das sind Referenzen.

Im C++ sinne sind es lustigerweise aber zeiger

man kann es nennen wie man will - insofern ist marketing blabla schon treffend (und die leute fallen massig drauf rein): zeiger in c++ und referenzen in java,... sind das exakt selbe konzept. ob man es nun zeiger oder referenz oder rebindable object nennen mag - es ist das selbe konzept.

der einzige unterschied ist, dass man in c++ zeiger incrementieren und decrementieren kann - das ist idr aber nie ein problem. das problem mit zeigern ist, dass sie wild sein koennen und da hilft einen auch kein gc dagegen. aber marketingmaessig sieht das natuerlich komplett anders aus...

c++ referenzen gibt es in der tat nirgendwo anders, zumindest nicht im mainstream bereich.

Andromeda

Shade Of Mine schrieb:

das problem mit zeigern ist, dass sie wild sein koennen und da hilft einen auch kein gc dagegen.

Java-"Zeiger" können nicht verwildern.

ThaRealMatix schrieb:

Was genau habe ich von Pointern?

Die Adresse und den Wert.

Shade Of Mine schrieb:

c++ referenzen gibt es in der tat nirgendwo anders

so eine tolle erfindung ist das aber auch nicht. ähnliches gibts schon lange.

int a;
#define A_REF a
A_REF = ...; // <-- verändert a

Simon2

fricky schrieb:

Shade Of Mine schrieb:

c++ referenzen gibt es in der tat nirgendwo anders

so eine tolle erfindung ist das aber auch nicht. ähnliches gibts schon lange.
int a;
#define A_REF a
A_REF = ...; // <-- verändert a

Doch - das "Tolle" an Referenzen (ggü. Deinem Ansatz) sind z.B.

ihre "Sichtbarkeit für den Compiler" ... was z.B. Typsicherheit und all die anderen Folgen nach sich zieht.
die Gültigkeit von Referenzen auch außerhalb der Sichbarkeit der "verwiesenen Variablen"
...

Und damit sind C++-Referenzen schon etwas "Neues" und "Tolles", weil sie vernünftig das Konzept des "festen Verweises" benutzbar umsetzen.

Gruß,

Simon2.

P.S.: "Getretener Quark wird breit, nicht stark" ... da helfen auch keine Smilies. Ich habe mit jedem Deiner Posts stärker den Eindruck, dass Du C++-Referenzen nicht wirklich durchschaut hast - aber einfach gerne widersprichst.

Simon2 schrieb:

Ich habe mit jedem Deiner Posts stärker den Eindruck, dass Du C++-Referenzen nicht wirklich durchschaut hast - aber einfach gerne widersprichst.

es ging mir nicht um die feinheiten. ich meinte, dass die idee, die selbe variable unter verschiedenen namen ansprechen zu können, keinen besonders brillianten geist erfordert. das bezog sich auf die aussage von shade'o'mine, der sagte: 'c++ referenzen gibt es in der tat nirgendwo anders'.

Simon2

Das mag sein, aber diese Analogie ist nicht Deine erste, die an der entscheidenden Stelle schräg ist ...

Shade hat auch nirgends "Genialität" postuliert, sondern lediglich "Einzigartigkeit" (bzw. "Seltenheit") ... damit ist nicht einmal ein positives Qualitätsmerkmal verbunden (man kann auch einzigartig dämlich sein ).

Gruß,

Simon2.

Andromeda

...

@Simon2:
exakt. Referenzen in C++ sind etwas dass es sonst kaum gibt. Punkt aus. Java hat keine Referenzen, PHP hat keine,...
Das sagt nichts über die wertigkeit aus. Aber es ist halt ein Fakt den viele übersehen weil der Name Referenz immer und überall fällt.

Andromeda schrieb:

Shade Of Mine schrieb:

das problem mit zeigern ist, dass sie wild sein koennen und da hilft einen auch kein gc dagegen.

Java-"Zeiger" können nicht verwildern.

Doch sehr wohl. Und das zeigt zB wieder dieses schöne "Marketing Bla Bla".

In Java kann ein Objekt einen ungültigen zustand haben. zB weil ich close() aufgerufen habe. Ergo kann eine Referenz auf ein ungültiges Objekt verweisen.

Es geht aber noch weiter: Referenzen in Java können aber auch auf zu alte Objekte zeigen die man nicht mehr verwendet und halt noch gültig sind weil der GC sie nicht weggeräumt hat aber eben bereits durch ein anderes Objekt ersetzt wurde. Ist btw sehr böse, weil es eben keine Fehlermeldung dann gibt.

Und die beliebten NullPointerExceptions gibts auch.

Ich sage nicht dass Referenzen in Java schlecht sind, ich sage nur dass Referenzen in Java das selbe Konzept wie Zeiger in C++ sind.

Andromeda

ShadeOfMine@work schrieb:

Andromeda schrieb:

Shade Of Mine schrieb:

das problem mit zeigern ist, dass sie wild sein koennen und da hilft einen auch kein gc dagegen.

Java-"Zeiger" können nicht verwildern.

...
In Java kann ein Objekt einen ungültigen zustand haben. zB weil ich close() aufgerufen habe. Ergo kann eine Referenz auf ein ungültiges Objekt verweisen.

Das Objekt existiert aber noch. Du hast hier keinen "Wild" Pointer.

ShadeOfMine@work schrieb:

Es geht aber noch weiter: Referenzen in Java können aber auch auf zu alte Objekte zeigen die man nicht mehr verwendet und halt noch gültig sind weil der GC sie nicht weggeräumt hat ...

Ja, siehe oben.

ShadeOfMine@work schrieb:

... aber eben bereits durch ein anderes Objekt ersetzt wurde.

Wie meinst Du das?

Simon2

Andromeda schrieb:

Shade Of Mine schrieb:

das problem mit zeigern ist, dass sie wild sein koennen und da hilft einen auch kein gc dagegen.

Java-"Zeiger" können nicht verwildern.

Das würde ich auch so sehen (wobei ich kein Javaspezi bin) ... hat aber nicht wirklich etwas mit "Zeigern" zu tun, sondern mit dem gesamten "Lebenszeitende"-Konzept, dass es in Java eben nicht gibt, das in C++ aber ein starkes Element ist.
Ergo: Diese "Nicht-Verwilderbarkeit" kostet auch einiges.

Einen echten Vorteil von "Java-Referenzen" ggü. "C++-Zeigern", sehe ich darin, dass Erstere beim erzeugen auf null gesetzt werden (IIRC !!)...
man kann also nicht vergessen, einen Zeiger mit 0 zu initialisieren - aber das ist IMHO kein konzeptioneller Unterschied, sondern eher ein kleiner Handlingsvorteil (mal ganz abgesehen davon, dass man natürlich auch in Java vergessen kann, eine Referenz auf das gewünschte Objekt umzubiegen).

Gruß,

Simon2.

Andromeda schrieb:

Wie meinst Du das?

Model m=obj.getModel();
obj.setModel(new Model());

m ist wild pointer

Tachyon

ShadeOfMine@work schrieb:

Andromeda schrieb:

Wie meinst Du das?
Model m=obj.getModel();
obj.setModel(new Model());
m ist wild pointer

Ohne zusätzliche Infos ist das nicht zwangsläufig der Fall.

Shade Of Mine

Tachyon schrieb:

Ohne zusätzliche Infos ist das nicht zwangsläufig der Fall.

"nicht zwangslaeufig" impliziert dass dies der fall sein kann.
q.e.d.

danke.

Tachyon

Shade Of Mine schrieb:

Tachyon schrieb:

Ohne zusätzliche Infos ist das nicht zwangsläufig der Fall.

"nicht zwangslaeufig" impliziert dass dies der fall sein kann.
q.e.d.

danke.

Nur, dass bei Deinen obigen Ausführungen jede Unsicherheit fehlt. Du stellst es als gegebenen Fakt dar.

Shade Of Mine

Tachyon schrieb:

Nur, dass bei Deinen obigen Ausführungen jede Unsicherheit fehlt. Du stellst es als gegebenen Fakt dar.

Ich zitiere dir mal mein gesagtes:

Referenzen in Java können aber auch auf zu alte Objekte zeigen die man nicht mehr verwendet und halt noch gültig sind weil der GC sie nicht weggeräumt hat aber eben bereits durch ein anderes Objekt ersetzt wurde. Ist btw sehr böse, weil es eben keine Fehlermeldung dann gibt.

Weiters spreche ich davon dass das objekt nicht mehr gebraucht wird - ich definiere also ganz klar den fall, dass es eben nicht gewuenscht ist dieses objekt noch zu verwenden. Das model Beispiel ist uebrigens ein super beispiel fuer wilde zeiger in java - sowas passiert oefters als man denkt.

hast du zu dem thema eigentlich noch etwas sinnvolles zu sagen?

Simon2

ShadeOfMine@work schrieb:

...

Model m=obj.getModel();
obj.setModel(new Model());

m ist wild pointer

Ehrlich gesagt, sehe ich da keinen "verwilderten Zeiger", wie man bei C oder C++ davon spricht. obj hat halt nicht mehr das Model-Objekt "im Bauch", auf das m zeigt .
Aber der GC sieht, dass durchaus noch eine Referenz auf dieses Objekt besteht und lässt es leben ....
Vielleicht ist das fachlich nicht unbedingt gewollt, aber technisch komplett unproblematisch.
Ich sehe auch kein "altes Objekt"....
Benenne einfach mal "m" um in "saveOldModel" und schon ergibt sich ein vollkommen sinnvolles Vorgehen (fachlich wie technisch).

Gruß,

Simon2.

und wenn man sich das genauer bedenkt ... sieht man wie mächtig zeiger eigentlich sind.

Bsp bei meinem aktuellen Projekt:
Massig Daten sollen berechnet werden.

da ist es doch sinnlos die alle über den Prozessorakumulator zu laden, auch wenn sie gerade nciht gebraucht werden.

mit pointern haste da echt n vorteil.
vor allem in der folgenden GPU- Verwertung

Shade Of Mine

Simon2 schrieb:

Vielleicht ist das fachlich nicht unbedingt gewollt, aber technisch komplett unproblematisch.

Das Programm laeuft falsch wegen einem Programmierfehler bezueglich der Lebenszeiten von Objekten.

Mir ist durchaus klar dass getModel seinen Sinn hat.
Aber ok, wenn ihr das nicht versteht, bitte:

dann etwas einfaches:

FileStream fs = obj.getFileStream();
obj.closeFileStream();

und schon ist fs ein wilder Zeiger.

Das Problem ist: nur weil das Objekt _lebt_ heisst es nicht dass es

das _richtige_ Objekt ist
und
das objekt sich im _richtigen_ zustand befindet.

Zeiger fehler != programm absturz.

Bei Zeigern sind die Probleme, dass die Objekte auf die man verweist sich aendern. Invalid werden, etc.

In Java sind Objekte zerstoert wenn man die letzte sinnvolle Referenz darauf fallen laesst - es ist aber gang und gaebe in Java dass es viele Referenzen gibt die nicht sinnvoll sind. Das fuehrt oft zu speicherproblemen weil der gc nicht killen kann.

das ist ein fakt. das ist ein problem mit dem java zu kaempfen hat. es ist kein show stopper aber es ist da.

weiters sind referenzen auf objekte die bereits zertoert werden haetten sollen insofern wilde zeiger - da schreib und lesezugriffe auf diese objekte undefiniertes verhalten erzeugen. undefiniert nicht im sinne von: absturz sondern im sinne von: nicht das was der caller machen wollte. er bekommt irgendwelche alten daten die vielleicht laengst veraltet sind zurueck oder schreibt daten ins nirvana. in c++ schmiert die anwendung ab in java passiert nichts.

aber der fehler ist IDENTISCH.

usw. usf.

Und nochmal:

delete p;

p ist jetzt nicht zwangslaeufig ein wilder zeiger. selbes bei getModel/setModel. Aber es KANN sein. Das ist der Sinn eines Beispiels.

**nochmal ganz langsam:

Zeiger Probleme sind nicht gleichbedeutend mit dem Absturz eines Programmes oder einem Buffer Overflow. Zeiger Probleme haben mit der validitaet von Daten zu tun.**