Delphi XE5 für Android

[mschnell]

http://www.heise.de/newsticker/meldung/ ... 46952.html

Hier werden also nun tatsächlich native-Code (ARM) Programme für Linux erstellt !!!

Aber ob das alles so schön ist ?!?!?!?
- völlige Zweiteilung in "Desktop" und "mobile" Entwicklungsumgebung (inkompatible visuelle Objekte, inkompatible Compiler und RTL (Funktionalität und teilweise Syntax)
- der "mobile" Compiler benutzt "Automatic Reference Counting" ("ARC", d.h. Alle Objekte werden automatisch gefreed, so wie es FPC ja bei Strings macht.) Hört sich praktisch an, wird aber sehr kontrovers diskutiert.
- keinerlei Support für Linux auf Desktop.

-Michael

[m.fuchs]

- der "mobile" Compiler benutzt "Automatic Reference Counting" ("ARC", d.h. Alle Objekte werden automatisch gefreed, so wie es FPC ja bei Strings macht.) Hört sich praktisch an, wird aber sehr kontrovers diskutiert.

Ich verstehe nicht warum alle Welt so einen Scheiß implementiert. Ist es so schwer die Objekte die man erzeugt hat auch wieder zu zerstören? Wer sowas will/braucht soll doch bitte zu JAVA oder .NET wechseln. In meinen Augen führt es nur zu unsauberen Code und aufgeblähten Programmen.

Außerdem ist das auch fachlich falsch. Referenzzählung ist keine Alternative zum Garbage Collector es ist eine Variante einen zu implementieren.

[mschnell]

Naja, ARC ist vermutlich weniger Laufzeit-kritisch als ein üblicher Garbage Collector wie bei Java, aber technisch eben ziemlich unzulänglich:

Es kann durchaus sinnvoll sein, Objekte am leben zu erhalten, auf die es keine Referenz gibt. Andererseits ist es auch nicht unbedingt sinnvoll, alle Referenzen auf ein Objekt zu löschen, wenn es nicht mehr gebraucht wird. Dann müsste ja beim freen eines Objektes "von Hand" jede enthaltene Referenz auf irgendein anderes Objekt gelöscht werden, nur um dessen Refernz-Couter zu dekrementieren.

Delphi Prism (.Net Framework), macht das natürlich richtig: Umgekehrt wird beim freen eines Objektes jede Referenz darauf gelöscht. Das geht aber nur in einem Framework und ist ziemlich ineffizient.

-Michael

[mse]

Delphi Prism (.Net Framework), macht das natürlich richtig: Umgekehrt wird beim freen eines Objektes jede Referenz darauf gelöscht.

Auch MSEgui hat so einen Mechanismus (iobjectlink). Sehr praktisch, wird auch zum Verteilen von object-events benützt.

[mschnell]

Interessant.

Ich verstehe allerdings nicht, wie das funktionieren kann.

-Michael

[mse]

Die Definition ist hier:
http://gitorious.org/mseide-msegui/msei ... seglob.pas
Die Implementation in tobjectlinker hier:
http://gitorious.org/mseide-msegui/msei ... lasses.pas

[Socke]

Es kann durchaus sinnvoll sein, Objekte am leben zu erhalten, auf die es keine Referenz gibt. Andererseits ist es auch nicht unbedingt sinnvoll, alle Referenzen auf ein Objekt zu löschen, wenn es nicht mehr gebraucht wird. Dann müsste ja beim freen eines Objektes "von Hand" jede enthaltene Referenz auf irgendein anderes Objekt gelöscht werden, nur um dessen Refernz-Couter zu dekrementieren.

Den letzten Satz unterschreibe ich. Bei dem ersten möchte ich dich ermuntern, noch einmal darüber nachzudenken: Wenn ich keine Referenz auf ein Objekt habe, kann ich nicht mehr darauf zugreifen. Es ist weg, fort, für immer.

[mschnell]

Wenn ich keine Referenz auf ein Objekt habe, kann ich nicht mehr darauf zugreifen. Es ist weg, fort, für immer.

Das ist natürlich nur in Spezialfällen möglicherweise sinnvoll.

Ein Objekt hat irgendein anderes Objekt oder einen Speicherbereich allokiert und der Zeiger darauf wurde übernommen. Dann braucht man das eigentliche Objekt nicht mehr.

Ein Objekt hat einen Thread und werkelt für sich alleine vor hin.

...

-Michael

[Socke]

Wenn ich keine Referenz auf ein Objekt habe, kann ich nicht mehr darauf zugreifen. Es ist weg, fort, für immer.

Das ist natürlich nur in Spezialfällen möglicherweise sinnvoll.

Ein Objekt hat irgendein anderes Objekt oder einen Speicherbereich allokiert und der Zeiger darauf wurde übernommen. Dann braucht man das eigentliche Objekt nicht mehr.

Ein Objekt hat einen Thread und werkelt für sich alleine vor hin.

Ja, aber dann habe ich doch eine Referenz. Dass ich im OOP-Sinne gar nicht von überall darauf zugreifen kann oder darf, steht dem gar nicht entgegen. Schließlich lege ich nicht alle TObject-Instanzen in einer globalen Liste ab, nur um eine Referenz zur Freigabe zu behalten. Wichtig ist, dass ich mindestens eine Referenz habe, auf die ich in einem definierten Rahmen zugreifen kann.

[Christian]

Auch in nem Thread existieren Zeiger auf das Object minddestens einer vom Thread aus, und vom Hauptprogramm einer auf den Thread. Dein Beispiel ist sinnfrei.

[mschnell]

Auch in nem Thread existieren Zeiger auf das Object minddestens einer vom Thread aus, und vom Hauptprogramm einer auf den Thread.

MyThread := TMythread.Create(...);

Erzeugt natürlich eine Referenz auf das TMyThread-Objekt (nicht auf "den Thread". Auch eine "Hauptprogramm" <-> "Unterprogramm" Beziehung gibt es hier nicht.)

Das TThread-Objekt kann dann selbstzständig "arbeiten"

Wenn ich dann

MyThread := NIL;

mache, gibt es keine Referenz auf das TMyThread -Objekt mehr. (Man könnte auch gleich TMyThread.Create(..) machen und die Referenz gar nicht speichern.)

Am Ablauf der Funktionalität ändert das nichts. Nur kann niemand mehr von außen den Thread "steuern".

(Klar ist das nicht unbedingt "sinnvoll", es soll ja auch nur das Prinzip verdeutlichen. Sinnvoll könnte es sein, wenn man 10000 Threads erzeugt, die man nicht von außen zu steuern braucht. )

Recht hast Du natürlich damit, dass innerhalb des Objektes selbst natürlich immer ein "Self" Pointer existiert. Ich glaube aber nicht, dass der bei ARC als Referenz gilt, sonst könnte der Referenz-Zähler ja nie auf 0 gehen und eine automatisches freeen veranlassen.

-Michael

[m.fuchs]

Wie wird dann sowas behandelt:

Code: Alles auswählen

with TJSONParser.Create(JsonString) do begin
  JsonObject := Parse AS TJSONObject;
  Free;
end;

Was ich mir auch noch vorstellen könnte wäre ein Objekt mit Methoden. Auf das Objekt selber gibt es keine Referenz, auf die Methoden schon.

Sind alles Spezialfälle, aber gerade die machen ja bei solchen Automatismen die Probleme aus.

[Socke]

MyThread := TMythread.Create(...);

Erzeugt natürlich eine Referenz auf das TMyThread-Objekt (nicht auf "den Thread". Auch eine "Hauptprogramm" <-> "Unterprogramm" Beziehung gibt es hier nicht.)

Die Referenz auf den Thread (Threadid) erstellt TThread selbstständig, ist also vorhanden.

Sinnvoll könnte es sein, wenn man 10000 Threads erzeugt, die man nicht von außen zu steuern braucht.

Bei welchen Aufgaben ist es für das ausführende Programm uninteressant, ob diese Ausgeführt werden? Schließlich lässt sich hier nicht einmal das Ergebnis abfragen. Selbstverständlich kann man eine Non-Blocking-Queue verwenden, um die Ergebnisse an das Hauptprogramm zurück zu leiten. Dann ist aber kein sauberer Abgang des Programms gewährleistet.

Wie wird dann sowas behandelt:

Code: Alles auswählen

with TJSONParser.Create(JsonString) do begin
  JsonObject := Parse AS TJSONObject;
  Free;
end;

Was ich mir auch noch vorstellen könnte wäre ein Objekt mit Methoden. Auf das Objekt selber gibt es keine Referenz, auf die Methoden schon.

Du glaubst jetzt nicht ernsthaft, dass hier keine Referenz auf das Objekt existiert?!
Wenn du keine Referenz auf ein Objekt hast, kannst du auch keine Methode aufrufen (das ist die Definition). Diese wird in der Variablen Self übergeben. Wenn keine Referenz vorhanden ist, kann nur ein konstanter Wert (nil) oder ein unbekannter Wert übergeben werden. Zugriff auf da Objekt hat man damit aber nicht mehr.

[mschnell]

Die Referenz auf den Thread (Threadid) erstellt TThread selbstständig, ist also vorhanden.

Es geht hier um "automatisches Reference counting" von Objekten da hat eine ThreadID überhaupt nix mit zu tun.

Bei welchen Aufgaben ist es für das ausführende Programm uninteressant, ob diese Ausgeführt werden? Schließlich lässt sich hier nicht einmal das Ergebnis abfragen.

Das TMyThread Objekt kann eine Referens auf ein anderes Objekt bekommen bevor man die Referens auf das TMyThread Objekt Nullt oder wieder verwendet. Dann kann s sich selbsttätig melden. (Wie gesagt das ist nur ein Beispiel...)

-Michael

[mschnell]

Du glaubst jetzt nicht ernsthaft, dass hier keine Referenz auf das Objekt existiert?!

Klar, existiert die, sie wird aber sofort wieder überschrieben. Bei "Automatic referenc counting" würde das Objekt dann automatisch gefreet. Das kann sinnvoll sein, muss aber nicht.

-Michael