Android: Grenzen objektorientierter Programmierung?

[Klaus Budmiger]

Nachfolgend ein Stück simplen Code das in Win32 problemlos geht aber in Android zu einem Fehler führt.
Hier das Vorgehen:

Ich bilde eine einfache Klasse mit einer Variable vom Typ String:
type
TMyString = class (TObject)
Text: String;
end;

Ich fülle eine TList mit einer Anzahl Instanzen:
List.Clear;
for i:=0 to 5 do
begin
MyString := TMyString.Create;
MyString.Text := IntToStr (i);
List.Add(MyString);
end;

Dann fülle ich die Werte aus der Liste in eine Listbox:
var i: Integer;
s: string;
begin
ListBox1.Clear;
for i:=0 to List.Count-1 do
begin
{in Android wird das nicht gelesen und führt zu einem Fehler:}
s := TMyString(List.Items[i]).Text;
ListBox1.Items.Add(s);
end;
end;

Kann mir jemand erklären warum geht dieser simpler Code in Android nicht?
Der ganze Code ist beigefügt.

[vagtler]

Schade, dass der Fehler so geheim zu sein scheint, dass Du ihn hier nicht darlegen darfst.

[Klaus Budmiger]

Pardon, natürlich:

Der Fehler im Android Tablet ist ein "Access violation at address ...." Fehler.
Wenn der Code ab der Zeile
s := TMyString(List.Items[i]).Text;
schrittweise verfolgt wird,

- dann ist die Anzahl der Einträge (List.Count) korrekt
- im Inspektor wird der Wert für den String s angegeben : <error reading addres 0x0: No error>
- wenn der Code weiterverfolgt wird, dann wird in der nächsten Schleife ein Debugger Exception Notifocation Fenster geöffnet mit der Meldung
"Project Project1.apk raised an exception class Segmenatation fault (11)." mit den Knöpfen "Break", "Continue", "Help".
Die Help Taste ist dieses Mail

[milos]

Wo hast du die Liste instanziert?

Edit: sry code is ja da, schaus mir gleich an ^^

[Stevie]

Auf Android greift ARC. Und da eine TList nicht typisiert ist und nur Pointer speichert, sorgt sie nicht dafür, dass deine TMyString Objekte am Leben bleiben. D.h. beim Verlassen der Methode bzw beim erneuten Zuweisen auf die MyString Variable, wo du die TList befüllst, sind sie schon wieder freigegeben worden. Demnäch stehen in der Liste bloß noch Pointer auf nicht mehr gültigen Speicher.

Um das zu lösen, würde ich für beide Plattformen vorschlagen, eine TList<TMyString> (oder auch direkt TList<string> oder TStringList) zu benutzen.
Hier auch drauf achten, dass du auf Windows keine Memoryleaks verursachst und deine TMyString Instanzen wieder richtig frei gibst, wenn die liste freigegeben wird (würde gehen, wenn du TObjectList<TMyString> benutzt)

Die findest du in der Unit System.Generics.Collections.

[Klaus Budmiger]

Herzlichen Dank für die Antwort. Das macht Sinn. Ich werde es so umsetzen.

[Dejan Vu]

Eine Verständnisfrage: ARC = Automatic Reference Counting. Bedeutet das in der Konsequenz, das ich mir um die Freigabe von Objekten keinen Kopf mehr machen muss?

Und wenn das so ist, warum ist das dann nur bei Android so?

[jaenicke]

Weil dort der neue Nextgen-Compiler benutzt wird. Der alte kann das nicht.

[Dejan Vu]

Also ist die Konsequenz, das Quellcode derzeit nicht zwingend kompatibel ist (wenn man old-style mit Pointern arbeitet).

Ferner deutet 'NextGen' darauf hin, dass das nur ein vorübergehender Zustand ist, da man bei 'next generation' davon ausgehen kann, das ein derartiger Compiler bzw. eine Spracherweiterung/veränderung auch für Windows umgesetzt wird, oder will man bei Emba etwa zweigleisig fahren?

[mkinzler]

Zitat:

Also ist die Konsequenz, das Quellcode derzeit nicht zwingend kompatibel ist (wenn man old-style mit Pointern arbeitet).

Bei etwas unglücklicher Programmierung kann das passieren. "sauberer" Code stellt aber kein Problem dar.

Zitat:

Ferner deutet 'NextGen' darauf hin, dass das nur ein vorübergehender Zustand ist, da man bei 'next generation' davon ausgehen kann, das ein derartiger Compiler bzw. eine Spracherweiterung/veränderung auch für Windows umgesetzt wird, oder will man bei Emba etwa zweigleisig fahren?

Es ist geplant, dass der neue auf LLVM basierende Compiler auch für Win32/Win64 zum Einsatz kommt. Bisher unterstützt er aber nur ARM für iOS und Android.