Was genau habe ich von Pointern?

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.**

Simon2

Shade Of Mine schrieb:

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

äh, nein, wieso ?

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

Die Lebenszeit des Objekts, auf das m verweist, endet doch nicht durch den folgenden setModel()-Call....

Anscheinend möchtest Du darauf hinaus, dass Objekte für bestimmte Operationen einen bestimmten Status verlangen (fachlich) ... aber das hat nichts mit Zeigern zu tun, sondern das müssen die Objekte sowieso entsprechend abfangen - und das versteht auch niemand, den ich kenne (außer Dir) unter "verwildertem Zeiger".
Das passiert Dir mit jeder Form von "Verweis" und betrifft ebenso C++-Referenzen, Handles, IDs, Primärschlüssel, ......

Auch hier:

Shade Of Mine schrieb:

...

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

passiert doch nichts Dramatisches, wenn via fs versucht wird, auf das Stream-Object zuzugreifen - weil es eben noch da ist !!
- Man kann sich immer noch den Filedescriptor holen und dessen Status abfragen
- Man kann ein read() ausführen ... und bekommt vom FileStream-Objekt eine definierte Exception
- ...
(in einer anderen Welt könnte man auch einfach wieder "open()" aufrufen )
Das ist schon ein qualitativer Unterschied zu den "verwilderten Zeigern", wie man sie in C und C++ hinbekommen kann, weil dort undefiniertes Verhalten erzeugt wird ... d.h. es kann gar keine Absicherung programmiert werden (weder beim Aufrufer noch innerhalb der Klasse), weil gar kein Objekt mehr existiert (und das OS an diese Speicherstelle bereits einen Codeabschnitt des Mediaplayers gelegt hat).
Insofern stimmt NICHT:

Shade Of Mine schrieb:

...
aber der fehler ist IDENTISCH.
...

Ich stimme Dir zu: In Java-Programm herrscht ein starker "Schnittstellen-Definitions-Mangel", der dadurch entsteht, dass es keine "const-Referenzen" gibt (sprich: Ich kann mir nie sicher sein, wer wann wie wo was mit meinem Objekt macht) ... aber das als "Problem mit verwilderten Zeigers" zu nennen, kenne ich bislang nicht und halte ich auch für ungeschickt, weil es ein konkretes Problem (undefiniertes und undefinierbares Verhalten) in einen Topf mit einer Vielzahl anderer Probleme wirft, die eine ganz andere Symptomatik aufweisen und ganz andere Techniken zur Lösung verlangen.
Ehrlich gesagt: Was Du ansprichst, ist nur die Forderung nach einer gut definierten "Statusmaschine" von Klassen (erst recht im Multithreading-Umfeld) - hier wird tatsächlich nicht selten geschludert - ein IMHO richtiger Hinweise ... an der falschen Stelle.

Gruß,

Simon2.

Simon2 schrieb:

Shade Of Mine schrieb:

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

äh, nein, wieso ?
Model m=obj.getModel();
  obj.setModel(new Model());
Die Lebenszeit des Objekts, auf das m verweist, endet doch nicht durch den folgenden setModel()-Call....

Doch. Sie endet.
Wir gehen nämlich davon aus, dass m auf das aktuelle Model verweisen soll. Das habe ich mehrfach gesagt. m zeigt aber nun auf eine veraltete Instanz die nicht mehr gebraucht wird und eigentlich schon tot ist.

Deshalb auch das Speicherproblem in Java - das tote Referenzen wie eben zB hier m Objekte am Leben erhalten. Wenn wir nun m verwenden um das model von obj zu manipulieren, haben wir inkorrekten Code.

In C++ wäre es das selbe - nur dass m auf ein zerstörter objekt verweisen würde.

Anscheinend möchtest Du darauf hinaus, dass Objekte für bestimmte Operationen einen bestimmten Status verlangen (fachlich) ... aber das hat nichts mit Zeigern zu tun, sondern das müssen die Objekte sowieso entsprechend abfangen - und das versteht auch niemand, den ich kenne (außer Dir) unter "verwildertem Zeiger".

Wilde Zeiger sind zeiger die nicht dorthin zeigen wo man er erwartet. Ist für dich die Definition eines wilden Zeiger das, dass das programm abstürtzt wenn man auf ihn zugreift?

Denk einmal an Iteratoren die invalid werden durch eine Operation an dem Container auf den sie verweisen. Dann hat man wilde iteratoren - oder meinetwegen invalide.

Das passiert Dir mit jeder Form von "Verweis" und betrifft ebenso C++-Referenzen, Handles, IDs, Primärschlüssel, ......

natürlich. wobei das bei referenzen schwer zu machen ist, aber gerade handles, ids, pkeys,... vielleicht sagt dir das wort "verwaiste xxx" mehr? verwaiste handles, verwaiste pkeys,... selbe sache.

Auch hier:

Shade Of Mine schrieb:
...
FileStream fs = obj.getFileStream();
obj.closeFileStream();
passiert doch nichts Dramatisches, wenn via fs versucht wird, auf das Stream-Object zuzugreifen - weil es eben noch da ist !!
- Man kann sich immer noch den Filedescriptor holen und dessen Status abfragen
- Man kann ein read() ausführen ... und bekommt vom FileStream-Objekt eine definierte Exception
- ...
(in einer anderen Welt könnte man auch einfach wieder "open()" aufrufen )
Das ist schon ein qualitativer Unterschied zu den "verwilderten Zeigern", wie man sie in C und C++ hinbekommen kann, weil dort undefiniertes Verhalten

dann gibt es per definition keine wilden zeiger, weil ich immer ein IsPtrValid() machen kann.

Es geht um die validität von daten um die aktualität. wenn ich auf ein objekt zeige das zerstört wurde (in java zerstört man mit close()) dann ist die referenz sofern ich ein valides objekt erwarte, fehlerhaft. selbes in c++, wenn ich auf ein zerstörtes objekt verweise ist das ok, solange ich nicht erwarte dass es nicht zerstört ist. und auch in c++ kann ich überprüfen ob das objekt lebt - auch wenn es nicht 100% sicher ist, aber IsPtrValid und konsorten können das idR ziemlich gut. Und ich kann das Objekt dann auch immer neu erstellen wenn ich will.

Aber bitte - dann gibt es in java eben keine toten referenzen.
Wenn du mal größere java/C#/... Anwendungen warten musst, wirst du aber merken dass dies durchaus ein problem ist dass zeitweise referenzen ungültig/veraltet/verwildert/verwaist/... sind. die 2 hauptprobleme betreffen dabei interne handles die nach aussen gegeben wurden und mittlerweile veraltet sind (zB iteratoren) und eben referenzen die objekte noch am leben erhalten die eigentlich schon längst tot sein sollten.

aber in der tat - das marketing von java/.net ist nicht schlecht: ein programm ohne absturz hat keine fehler.

das gefährliche an den verwaisten referenzen in c#/java/... ist aber eben dass das programm _nicht_ abstürtzt. es läuft fehlerbehaftet weiter.

solche fehler gibt es. die gibt es in c++ ja auch. die gibt es überall wo man zeiger hat. weil immer wenn ich referenzen auf objekte habe (ids sind nichts anderes als eine referenz auf ein objekt - oder zB die hashkeys in einer hash map) kann sich das objekt ändern ohne dass ich es erwarte.

bei ids und pkeys, etc. ist es eine spur etwas anderes, da man auf eine stelle verweist und einem egal ist welches objekt dort liegt. bei zeigern/handles ist es etwas problematischer da auf das objekt verweist wird und wenn das objekt ersetzt wird, bekommt der zeiger dass nicht mit.

aber ich glaube ich rede schon wieder nicht von der direkten java definition und deshalb versteht das keiner. also gut: was ist deine definition eines wilden zeigers. zeig mir c++ code der einen wilden zeiger produziert (ohne inc/dec des zeigers bitte, sonst wird es etwas abstrakt und dann versteht es keiner.

wichtig ist, dass man erkennt dass close() in java ein destruktur aufruf ist. und ein neues open wäre wieder ein ctor aufruf.

Simon2

Hi shade,

(Ich sollte vielleicht mal vorweg stellen, dass ich eine mindestens so kritische Einstellung zum Java-Hype und -Marketing habe, wie Du und selbst fast ausschließlich in C und C++ programmiere)

Du versuchst, Deine Aussage mit Redefinition bereits eindeutig belegter Begriffe zu retten, aber das wird nichts werden...
"Lebenszeitende" = Dtor/finally() wird aufgerufen = Objekt ist danach auf Sprachebene nicht mehr verfügbar.
... und nichts Anderes, kein close(), kein beendeMich(), kein setStateDeleted(), ....
"gültiges Objekt" = Nach Lebenzeitbeginn und vor Lebenszeitende
... und nichts Anderes, kein "stateFlag == INVALID", "eigentlich sollte man das Objekt lieber nicht mehr lesen, ...

Ich will nicht sagen, dass die Dinge, die Du sagst, sinnlos seien ... aber das hat eben einfach nichts mit dem Thema zu tun. Natürlich steht es Dir frei, eigene Definitionen anzuführen - aber dann hat eine Kommunikation keinen großen Sinn (oder wir müssten eben lang und breit über den Inhalt und Sinn der jeweiligen Diskussionen reden).

BTW: Ebenfalls die Aussage, Java habe "ein Speicherproblem", höre ich zum ersten Mal.

ShadeOfMine@work schrieb:

...
...Wilde Zeiger sind zeiger die nicht dorthin zeigen wo man er erwartet. ..

Aber die Kopie zeigt noch genau dahin, wohin man das erwartet - auf dasselbe Objekt.
Der Effekt wäre derselbe, wenn der FileStream bereits vor der Übergabe ge-close-ed worden wäre.

ShadeOfMine@work schrieb:

...
Ist für dich die Definition eines wilden Zeiger das, dass das programm abstürtzt wenn man auf ihn zugreift?...

zeige mir doch bitte einmal das Wort "Absturz" in meinem Post...

ShadeOfMine@work schrieb:

...
Dann hat man wilde iteratoren - oder meinetwegen invalide....

Aber genau DA liegt ja der Unterschied: "wild" != "invalid" (deutsch)
und selbst wenn wir nicht das Wort "wild" verwenden wollen, geht es hier nur um das Phänomen "Verweis auf totes Objekt".

ShadeOfMine@work schrieb:

...
dann gibt es per definition keine wilden zeiger, weil ich immer ein IsPtrValid() machen kann....

Nein, kannst Du nicht, weil jeder Zugriff auf einen verwilderten Zeiger undefiniert ist.

ShadeOfMine@work schrieb:

...
Es geht um die validität von daten ...

Dir schon, hier im Thread nicht. Hier geht es um die ganz spezielle Gefahr undefinierten Verhaltens dadurch, dass ein Zeiger auf ein bereits zerstörtes Objekt zeigt und man keine Chance hat, das herauszufinden.

ShadeOfMine@work schrieb:

...in java zerstört man mit close() ...

Dafür hätte ich gerne mal einen Beleg.

ShadeOfMine@work schrieb:

...Wenn du mal größere java/C#/... Anwendungen warten musst, wirst du aber merken dass dies durchaus ein problem ist dass zeitweise referenzen ungültig/veraltet/verwildert/verwaist/... sind....

Das weiß ich durchaus und habe es auch nie geleugnet (im Gegenteil: immer darauf hingewiesen) - aber es ist ein anderes Problem, das Du auch in Sprachen hast, die das hier deiskutierte "verwildertes Zeiger-Problem" nicht haben.
Nimm einfach mal eine Sprache an, die gar keine Objektzerstörung hat; jedes einmal erzeugte Objekt lebt in alle Ewigkeit ... trotzdem hat man das von Dir angesprochene Problem, dass ein Objekt in einem bestimmten fachlichen Status eine bestimmte Operation nicht sinnvoll ausführen kann.
Der wichtigste "Lackmustest", um zwischen den beiden Problemklassen zu unterscheiden ist die Frage: "Kann ich die Situation innerhalb meines Programms zuverlässig 'retten' ?"

"Deine" Fälle kann man immer retten: Eine Status-Abfrage, eine geworfene/gefangene Exception, ....
Meinen Fall (s.u.) kannst Du nicht retten.

ShadeOfMine@work schrieb:

...aber in der tat - das marketing von java/.net ist nicht schlecht: ein programm ohne absturz hat keine fehler....

das gefährliche an den verwaisten referenzen in c#/java/... ist aber eben dass das programm _nicht_ abstürtzt. es läuft fehlerbehaftet weiter....

Stimme ich Dir voll zu - aber eben: Kein Thema hier.

ShadeOfMine@work schrieb:

...also gut: was ist deine definition eines wilden zeigers....zeig mir c++ code der einen wilden zeiger produziert (ohne inc/dec des zeigers bitte, sonst wird es etwas abstrakt und dann versteht es keiner...

Gerne (der Klassiker):

A* a;
{
   A b;
   a = &b;
}
a->methode(); // undefiniert

Hier hat weder der Besitzer von a noch der von b eine Chance, die Situation zu retten. Hier kann man letztlich nur Zeiger "verbieten" (und stattdessen nur smart_Pointer-Konstrukte zulassen).
...und sowas kriegst Du in Java einfach nicht hin.

Gruß,

Simon2.

Chewie83

Ohne jetzt den Rest zu kommentieren:

ShadeOfMine@work schrieb:

wichtig ist, dass man erkennt dass close() in java ein destruktur aufruf ist. und ein neues open wäre wieder ein ctor aufruf.

Das ist definitiv falsch. Es gibt im engeren Sinn bei Java gar keine Destruktoren, sondern nur sogenannte Finalizer. Ob das jetzt das gleiche ist oder nicht, wäre eine andere Diskussion. Aber eine Methode close() aufzurufen ist ein ganz normaler Methodenaufruf - der den Objektstatus ändern kann, wie er will. Du spielst wahrscheinlich auf die Java-IO-Klassen an, die größtenteils eine solche Methode haben - diese dient aber nicht zum Zerstören des Objektes, sondern zum Schließen der zugeordneten externen Ressourcen.

Alles andere hat Simon2 schon gesagt.

Tachyon

Wer segt überhaupt, dass Model nicht clonable ist? So wie Dein Beispiel gehalten ist, kann m alles mögliche sein. Nur "hängend" ganz bestimmt nicht.

Simon2 schrieb:

A* a;
{
   A b;
   a = &b;
}
a->methode(); // undefiniert

Easy Cheesy:

A a;
{
  A b=new A();
  a=b;
  b.close();
}
a.methode(); // Exception

Jetzt wirst du sagen in Java kann man ein

if(a.isOpen())

machen - aber genauso kann ich in C++ ein

if(IsPtrValid(a))

Mal von anderen Techniken abgesehen. Das lustige ist, es passiert bei beiden Codes das selbe: es tritt eine "Illegal State" Situation ein

In C++ kann man hier super Hardware Exception stattdessen fangen, wenn du soviel wert auf exception legst.

PS:
Wer finalizer mit Destruktoren gleichsetzt und nicht close Methoden, der hat etwas grundlegendes in Java nicht verstanden...

Und es gibt keine Diskussion was mein Beispielcode macht. Ich hab es gesagt was er macht. Und getModel clont nicht - könnt ihr überhaupt Java? Schonmal in Java programmiert? Oder rede ich hier mit Leuten die keine Ahnung von Java haben?

Kommt mir nämlich so vor... Also welche Sprache kennt ihr denn? Dann machen wir es in der. Kein Problem.

DerKuchen

ShadeOfMine@work schrieb:

Easy Cheesy:

A a;
{
  A b=new A();
  a=b;
  b.close();
}
a.methode(); // Exception

Das Objekt a exisitert aber noch, immerhin kann es eine Exception werfen. Mit anderen Worten, der Zustand ist genau definiert, was der Unterschied zu C++ ist.

ShadeOfMine@work schrieb:

Jetzt wirst du sagen in Java kann man ein
if(a.isOpen())
machen - aber genauso kann ich in C++ ein
if(IsPtrValid(a))

Wie soll denn IsPtrValid aussehen? Ein wilder Pointer hat ja kein spezielles aussehen, sonst wär er nicht wild.

ShadeOfMine@work schrieb:

Mal von anderen Techniken abgesehen. Das lustige ist, es passiert bei beiden Codes das selbe: es tritt eine "Illegal State" Situation ein

Der Unterschied ist, dass in Java diese "Illegal State" genau definiert ist, es wird eine Exception geworfen. In C++ kann alles passieren.

Ich hab eher wenig Ahnung von Java, aber so weit ich weiß, werden Objekte erst dann vom GC weggeräumt, wenn es keine Referenz mehr darauf gibt.
Da ein wilder Pointer ein Pointer auf ein Speicherbereich ist, in dem nichts definiertes mehr vorzufinden ist, kann es ihn in Java nicht geben. Solange ich den Pointer habe, kann das Objekt davon nicht nicht exisiteren. Klar kann es eine Exception auswerfen, weil es im Kontext der Programmlogik nicht mehr funktioniert, aber auf Sprachebene ist es ein valides Objekt.

Simon2

Du bestätigst mich:

ShadeOfMine@work schrieb:

Simon2 schrieb:

...a->methode(); // undefiniert

...

a.methode(); // Exception

Eben: Exception != undefiniert

ShadeOfMine@work schrieb:

...
machen - aber genauso kann ich in C++ ein
if(IsPtrValid(a))

Nein - eben nicht.

ShadeOfMine@work schrieb:

...In C++ kann man hier super Hardware Exception stattdessen fangen, ...

Nein, kann man eben NICHT !!!
Denn es muss keine Hardware-, OS- oder sonstige Exception fliegen!!
Es kann genausogut

methode() erfolgreich auf korrekten Daten oder
methode() erfolgreich auf falschen Daten oder
methode() nicht erfolgreich (verändert anderes als gedacht) auf korrekten Daten oder
methode() "irgendwie" oder
eine andere Memberfunktion eines ganz anderen Objekts einer anderen Klassen ausgeführt werden,
ganz anderer Code durchlaufen werden,
das Betriebssystem abrauchen,
die Platte formatiert werden,
...
und das jeweils je nach "Tageslaune des Systems" (also bei jedem Durchlauf was Anderes)

Das versteht man unter "undefiniert" .... und genau DA liegt das Problem.
(mir gehen langsam die Beschreibungsalternativen von "undefiniert" aus)

ShadeOfMine@work schrieb:

PS:
Wer finalizer mit Destruktoren gleichsetzt ...

Habe ich nicht gemacht, wie Dir anscheinend entgangen sein dürfte. Ich habe lediglich gesagt, ab wann in der jeweiligen Sprache das "Lebensende" eines Objekts definiert ist.

Gruß,

Simon2.

P.S.: Lass doch bitte die vollkommen überflüssigen "Ihr-habt-ja-alle-keine-Ahnung"-Ausflüge. Bringt keinem etwas ...

Andromeda

ShadeOfMine@work schrieb:

aber in der tat - das marketing von java/.net ist nicht schlecht: ein programm ohne absturz hat keine fehler.

Das Marketing von Java und .NET lügt nicht. Niemand sagt, daß Java-Programme nicht abstürzen können. Das können sie sehr wohl, oft mit der allseits bekannten Nullpointer-Exception. Was sie aber nicht können ist, mit wilden Pointern unkontrolliert im Speicher wüten, weil es dort keine wilden Pointer geben kann.

ShadeOfMine@work schrieb:

das gefährliche an den verwaisten referenzen in c#/java/... ist aber eben dass das programm _nicht_ abstürtzt. es läuft fehlerbehaftet weiter.

Jedes System und jede Programmiersprache hat ihre eigenen Fehlermöglichkeiten. Wie Java ausschweifende Pointer-Manipulation verhindert, ist vielleicht nicht perfekt, aber ein großer Vorteil im Vergleich zu Sprachen wie C. Du solltest vielleicht auch mal daran denken, daß Java und C für komplett andere Anwendungsgebiete geeignet sind. C setzt auf Geschwindigkeit und kleine Binaries. Pointer müßen deshalb ohne Runtime-Checks in direkte Speicherzugriffe übersetzt werden. C wird daher oft in Embedded Systemen, für Systemprogrammierung und für Treiber eingesetzt. In C ist dem Programmierer nahezu alles erlaubt. C geht davon aus, daß mündige und talentierte Leute Programme schreiben. Im Gegensatz dazu erlaubt Java bereits mittelmäßig erfahrenen Programmierern aufwendige Programme zu schreiben, ohne daß sie alle 5 Zeilen in eine "Undefined Behavior" oder "Dangling Pointer" -Falle tapsen.

ShadeOfMine@work schrieb:

solche fehler gibt es. die gibt es in c++ ja auch. die gibt es überall wo man zeiger hat. weil immer wenn ich referenzen auf objekte habe (ids sind nichts anderes als eine referenz auf ein objekt - oder zB die hashkeys in einer hash map) kann sich das objekt ändern ohne dass ich es erwarte.

Du vergleichst Äpfel mit Birnen. Handles, IDs, usw. sind abstrahierte Verweise auf Objekte, über die das Programm (oder die VM) absolute Kontrolle hat und die jederzeit validiert werden können. Wohingegen "echte" Pointer, wenn sie erstmal losgelassen und verwildert sind, sich jeder Einflußnahme entziehen. Beispiel: Versuch doch mal einen Nullpointer-Zugriff mit einer C++ Exception zu fangen.

Badestrand

Ist es nicht eigentlich auch eine Art "undefiniertes Verhalten" für das Programm, wenn es nicht das macht, was vorgesehen ist, eben durch das Arbeiten auf einer veralteten Referenz?