Cross-Platform-Komponenten etwickeln?

[himitsu]

Witzig, grade eben wollte ich das auch fragen
http://www.delphipraxis.net/178185-g...nd-mobile.html

Allerdings mehr in Bezug auf die RTL, alsnstat auf die VCL FMX.
(Warum heißt das eigentlich nicht XCL? )

Hier fing das ja schonmal an.
http://www.delphipraxis.net/178157-v...unter-ios.html
Probleme für gemeinsam verwendeten Code, durch verändertes Verhalten bei der String-Indizierung.



Wie sieht das aber mit den Klassen aus?

Wenn ich das wichtig mitbekommen hab, dann wurden im iOS und vermutlich auch beim Android die Klassen um eine Referenzzählung (ARC) erweitert
und das Free ist nur noch eine Dummy-Prozedur (zur Code-Kompatibilität), die aber nichts mehr macht.
(Der direkte Aufruf von Destroy ist nun also erst Recht ein Fauxpas)
http://docwiki.embarcadero.com/RADSt...lphi-Compilern

In OSX gibt es kein ARC?


In Windows wollte ich eine Komponente auf Interfaces umstellen, aber wenn die automatische Zählung im mobilen Bereich nun direkt geht:
Ist es dann besser, dort das direkt als Klassen zu lassen und/oder wie sieht es dort mit den Interfaces aus?


Und wie sieht das mit dem Variant aus?
Hat der im Mobilen irgendwelche Nachteile? Im Windows hatte Borland dort ja einige delphieigene Typen "reingehackt".

[Sir Rufo]

Bei Strings nimm anstatt

Delphi-Quellcode:

for i := 1 to Length( str ) do
begin

end;

dieses (hab es nicht probiert, müsste aber gehen)

Delphi-Quellcode:

for i := Low( str ) to High( str ) do
begin

end;

Nimm bei Klassen FreeAndNil das passt dann immer

Interfaces sind von der Behandlung gleich.

[Bernhard Geyer]

Zitat von Sir Rufo:

Bei Strings nimm anstatt

Delphi-Quellcode:

for i := 1 to Length( str ) do
begin

end;

dieses (hab es nicht probiert, müsste aber gehen)

Delphi-Quellcode:

for i := Low( str ) to High( str ) do
begin

end;

Dafür wurde die TStringHelper-Klasse eingeführt.
Die korrekte gleiche Verwendung (wie auch in der Hilfe als Beispiel vorhanden) wäre:

Delphi-Quellcode:

  for I:= 0 to MyString.Length - 1 do
    Write(MyString.Chars[I]);

Zitat von Sir Rufo:

Nimm bei Klassen FreeAndNil das passt dann immer

Eigentlich nicht. In den Meisten Fällen ist ein .Free besser/angebrachter. Sollte FreeAndNil Abstürze vermeiden so hat man meiste an anderer Stelle ein Problem/Fehler der durch ein FreeAndNil umschifft wird. Nick hat auch mal was zu dem Thema geschrieben: http://www.nickhodges.com/post/Using-FreeAndNil.aspx

[Union]

Zitat von Sir Rufo:

Nimm bei Klassen FreeAndNil das passt dann immer

Leider nicht. Gerade zur Laufzeit erstellte Komponenten erhalten so viele Referenzen, dass ARC das nicht mehr mitbekommt. Dort ist dann Release zu verwenden.

[arnof]

Zitat von Union:

Zitat von Sir Rufo:

Nimm bei Klassen FreeAndNil das passt dann immer

Leider nicht. Gerade zur Laufzeit erstellte Komponenten erhalten so viele Referenzen, dass ARC das nicht mehr mitbekommt. Dort ist dann Release zu verwenden.

Für Komponenten sollte man schon immer Release verwenden (habe ich aber erst bei einer Schulung von Deveperts gelernt) Damit wird auch die Ereignissbehandlung richtig geschlossen!

Da habe ich bei einen Delphi 5 Projekt nun keine Schutzverletzung aus heiterem Himmel mehr beim Beenden des Programms!

Zu den Stringbehandlungen kann ich folgenden Tipp geben:

Delphi-Quellcode:

x: string;

…
   {$IFDEF NEXTGEN}
   for i:= 0 to Length(x)-1 do begin
   {$ELSE}
   for i:= 1 to Length(x) do begin
   {$ENDIF}

[himitsu]

Grade für Komponenten ist das jetzt der totale Mistehaufen.
Die String-Helper kann man nicht verwenden, wenn man den Code auch für ältere Delphi bereitstellen will, außer man baut sich da wieder eigene Helper, welche dann über Compilerswitches reinelinkt werden. (so kommt man zumindestens noch bis D2006 runter)

Aber grade wegen der Objekt-Referenzen hab ich eben ein Problem.
- im Mobile-Compiler auch Interfaces verwenden (gibt es da eventuelle Nachteile), oder lieber "native" Objekte
- bei ARC intern auf die Referenzen achten, wenn man extern Interfaces bereitstellt
- in Windows/Desktop mit Interfaces zum Nutzer (und intern natürlich Objekte)
- ...

Hatte vor knapp 2,5 oder 3 Wochen eine Anfrage bekommen, wie es beim himXML mit X-Platform aussieht.
Dort handelt es sich um mehrfach querverlinkte Objekt-Referenzen wo ich jetzt dank ARC jetzt noch mehr auf die Referenzzählung achten darf. (auch ohne ist das nicht einfach)
Was noch "übersichtlicher" wird, wenn ich bei ARC Interface- und Objektreferenzen verwende, wo "früher" bei den Objekten nicht auf eine Referenzzählung geachtet werden mußte.

Wie ist das beim ARC denn jetzt nun mit den Weak-Pointern?

Schon mit XE3 fing das Chaos an und keiner wusste was, also legte ich alles auf Eis und wollte mal schauen wie es nun wirklich weitergeht.
http://blog.synopse.info/post/2012/1...lass-instances
http://docwiki.embarcadero.com/RADSt...lphi-Compilern
Aber dank eines fehlenden aktuellen Compilers kann ich alles nur "theoretisch" schreiben und hoffen es läuft dann auch so, wie ich es mit dachte.

[Bernhard Geyer]

Zitat von himitsu:

Grade für Komponenten ist das jetzt der totale Mistehaufen.
Die String-Helper kann man nicht verwenden, wenn man den Code auch für ältere Delphi bereitstellen will, außer man baut sich da wieder eigene Helper, welche dann über Compilerswitches reinelinkt werden. (so kommt man zumindestens noch bis D2006 runter)

Irgendwann muss mal Altsysteme abkündigen. Ist wie mit alten Windows-Versionen. Man wird zwar länger Support bieten als der Hersteller aber irgendwann muss man mal los lassen.
Wie soll der Hersteller (hier Emba) neu (nötige) Sprachfeaters aufnehmen wenn es dann immer wieder heißt: "das geht ja wieder in meinem 10 Jahre alten IDE-Version".

Zitat von himitsu:

Wie ist das beim ARC denn jetzt nun mit den Weak-Pointern?

Also ich finde es gut das man langsam auch solche Möglichkeiten bekommt. Man kann zwar auch ohne solche Arbeiten, aber die Implementierungen sind umfangreicher und auch fehlerhafter als solche weak-Pointer.

[Bernhard Geyer]

Leider nicht. Gerade zur Laufzeit erstellte Komponenten erhalten so viele Referenzen, dass ARC das nicht mehr mitbekommt. Dort ist dann Release zu verwenden.[/QUOTE]
Also ich kenn nur die Aussage das man Release für Nicht-Modale Dialoge verwenden soll. Für alles andere reicht ein Free.

Zitat von arnof:

Für Komponenten sollte man schon immer Release verwenden (habe ich aber erst bei einer Schulung von Deveperts gelernt)

Wie soll das gehen wenn TComponent gar keine Release-Methode hat

Zitat von arnof:

Da habe ich bei einen Delphi 5 Projekt nun keine Schutzverletzung aus heiterem Himmel mehr beim Beenden des Programms!

Ich Tipp hier eher auf das Umschiffen eines anderen (eigenen/VCL) Programmfehlers.
Z.B. gabs bei uns mit D5 sporatische Abstürze mit einem DB-Projekt. Bis ich heraus gefunden hat das in der BDE knallhart auf Screen.Curser zugegriffen wurde obwohl beim beenden die Screen-Instanz schon freigegeben war.

Zitat von arnof:

Zu den Stringbehandlungen kann ich folgenden Tipp geben:

Delphi-Quellcode:

x: string;

…
   {$IFDEF NEXTGEN}
   for i:= 0 to Length(x)-1 do begin
   {$ELSE}
   for i:= 1 to Length(x) do begin
   {$ENDIF}

Und was spricht gegen die dafür vorgesehenen Helper-Klassen? Ein Code der mit tausenden NEXTGEN-Ifdefs durchsäht ist, ist nicht gerade übersichtlich und einfachz zu pflegen. Haben hier noch 1-2 Bibliothekten (in älterer Version) die noch mit VCL.NET-Code "verseucht" sind.

[arnof]

Zitat:

Also ich kenn nur die Aussage das man Release für Nicht-Modale Dialoge verwenden soll. Für alles andere reicht ein Free.

Wie soll das gehen wenn TComponent gar keine Release-Methode hat

Ganz cool, Release halt nicht Tcomponent, aber für alle Komponenten die eine Ereignisbehandling haben, Du weist schon wie ich das meine; also keine Erbsen zählen.

Zitat:

Ich Tipp hier eher auf das Umschiffen eines anderen (eigenen/VCL) Programmfehlers.
Z.B. gabs bei uns mit D5 sporatische Abstürze mit einem DB-Projekt. Bis ich heraus gefunden hat das in der BDE knallhart auf Screen.Curser zugegriffen wurde obwohl beim beenden die Screen-Instanz schon freigegeben war.

Ja sowas in der Art meine ich. Dinger von anderen die Irgendwas irgendwann machen wo man nicht mehr Debuggen kann. Hier hat Release gute Dienste geleistet, wo ich vorher mal das Programm 100 Application.ProcessMessages laufen ließ um die Probleme in den Griff zu bekommen!

Zitat:

Und was spricht gegen die dafür vorgesehenen Helper-Klassen? Ein Code der mit tausenden NEXTGEN-Ifdefs durchsäht ist, ist nicht gerade übersichtlich und einfachz zu pflegen. Haben hier noch 1-2 Bibliothekten (in älterer Version) die noch mit VCL.NET-Code "verseucht" sind.

Kann man sicher machen, ich habe nur meine Lösung aufgezeigt. Dein Beispiel was Du hier mit der Helperclasse aufgezeigt hast geht NICHT bei den Mobilen Geräten da hier der String bei 1 und nicht bei 0 anfängt! Ob das Beispiel von SirRufo geht kann ich nicht sagen, das währe die "sauberste Lösung". Oder am Projektanfang entsprechende Start und Entkonstanten definieren!