IDE und IFDEFs für verschiedene Plattformen

[bra]

Wir haben in unserer App durch die verschiedenen Plattformen inzwischen reichliche IFDEFs enthalten. Leider führt das dazu, dass teilweise die Codeerweiterung nicht mehr richtig funktioniert (wenn Android eingestellt ist, meist gar nicht :roll:) und auch das Hin- und Herspringen zwischen Interface und Implementation nicht mehr geht, wenn die komplette Funktion innerhalb eines IFDEFs ist. Alles in separate Units aufzuteilen ist meiner Meinung nach auch Overkill, weil es oft nur 2-3 Funktionen sind, die für die Plattform speziell sind.

Hat da jemand einen Tipp, wie man das beheben kann oder wie macht ihr das?

[himitsu]

Beheben?

Garnicht.
Ich hab da einfach das Gefühl, daß Funktionen wie ErrorInsight, CodeInsight, Refactoring usw. nicht alle DEFINES richtig setzen, so wie sie sein würden, wenn man das mit den aktuellen Projektoptionen kompilieren würde.
(bei denen läuft ja entweder ein Parser oder ein BackgroundCompiler über den Code, welche das entsprechend richtig beachten müssten)

CompilerVersion, VERxxx, DEBUG, RELEASE, die vielen DEFINES der verschiedenen Plattformen, ...

[bra]

Ich habe mal einen QC-Eintrag erstellt, vielleicht hilfts ja was... https://quality.embarcadero.com/browse/RSP-15580

[Bambini]

Auch schick ist das es kein eigenes IFDEF für MACOS gibt, da es MACOS seltsamerweise auch beim Ziel iOS gibt, obwohl da IOS aktiv ist. Verstehe wer will.
Das macht den gemeinsamen Code für MacOS/iOS nicht übersichtlicher.

Nachtrag:
Um es dann noch einmal komplizierter zu machen. Ist MACOS bei der iOS 32-Bit dabei, aber nicht (mehr) bei 64-Bit. Nee, is' klar.
http://docwiki.embarcadero.com/RADSt...ierung_(Delphi)

[Stevie]

Zitat:

Zitat von Bambini (Beitrag 1343978)

Um es dann noch einmal komplizierter zu machen. Ist MACOS bei der iOS 32-Bit dabei, aber nicht (mehr) bei 64-Bit. Nee, is' klar.
http://docwiki.embarcadero.com/RADSt...ierung_(Delphi)

Das ist ein Fehler in der Doc, habe es gerade getestet und reported:
https://quality.embarcadero.com/browse/RSP-15581

[Rollo62]

Ja ich weiss: du möchtest jetzt wahrscheinlich nicht allzuviel umstellen.

Aber ich lege meinen Code wenn möglich separat für verschiedene Plattformen an, also

Delphi-Quellcode:

Unit MyCode;  // Das hier benutze ich in den Apps

uses
  System.Types
{$IFDEF WIN32}
  ,MyCode.Win32
{$ENDIF WIN32}
{$IFDEF WIN64}
  , MyCode.Win64
{$ENDIF WIN64}
{$IFDEF OSX}
  , MyCode.OSX
{$ENDIF OSX}
  ;

Auch bei wenig Code ist das die sauberste Methode, und sollte auch unütze Referenzierungen vermeiden,
wenn es bei Android und iOS mal sparsam zugehen muss.

Ich finde der Mehraufwand lohnt sich schon auf lange Sicht, und alles bleibt gut überschaubar und wartbar.

Rollo

[Bambini]

Zitat:

Zitat von Rollo62 (Beitrag 1344002)

Ja ich weiss: du möchtest jetzt wahrscheinlich nicht allzuviel umstellen.

Aber ich lege meinen Code wenn möglich separat für verschiedene Plattformen an, also

Delphi-Quellcode:

Unit MyCode;  // Das hier benutze ich in den Apps

uses
  System.Types
{$IFDEF WIN32}
  ,MyCode.Win32
{$ENDIF WIN32}
{$IFDEF WIN64}
  , MyCode.Win64
{$ENDIF WIN64}
{$IFDEF OSX}
  , MyCode.OSX
{$ENDIF OSX}
  ;

Auch bei wenig Code ist das die sauberste Methode, und sollte auch unütze Referenzierungen vermeiden,
wenn es bei Android und iOS mal sparsam zugehen muss.

Ich finde der Mehraufwand lohnt sich schon auf lange Sicht, und alles bleibt gut überschaubar und wartbar.

Hm, vielleicht verstehe ich es nicht richtig, das uses in deiner MyCode Unit führt nicht dazu, dass die Klassen, Funktion & Co. der MyCode.xx Unit nach außen sichtbar sind.
Das bekommt nur ein unschönes {$INCLUDE ...} hin oder wie es Delphi macht, ein wildes RegisterXYZ in der initialization Section.
Schicke wäre die gleiche Art wie das Unit-Gültigkeitsbereichsnamen, nur diesmal für das Suffix, in den Projekteigenschaften für jede Plattform.
Setzt man da z.B. in dem Ziel für "Alle Konfigurationen - 32-Bit-Windows" ein 'win' ein, Sollte Delphi versuchen zuerst die MyCode.win.pas zu verwenden obwohl im Code nur uses MyCode steht, gibt es die nicht dann die MyCode.pas.
Das finde ich sehr elegant.

[himitsu]

Du kannst auch den Standard-NameSpace verwenden.
Macht Embarcadero auch so.
Bei VCL-Projekten ist "Vcl" eingetragen und bei den Affen halt "Fmx".
In den Uses steht dann "Forms" und verwendet wird da dann jeweils "Vcl.Forms.pas" oder "Fmx.Forms.pas". (drum knallt es da gern beim Upgrade alter Projektdateien, da dort der Vcl-Namespace noch nicht definiert ist :stupid:)

Du kannst da bei deinen Plattformen jeweils "Win" (oder "Win32" bzw. "Win64"), "OSX", "IOS" usw. eintragen, bei den entsprechenden Build-Konfigurationen in der Projektoption.
Bzw. bei Win32 wird "Win" und "Win32" definiert, denn dann kann man "Win.MyCode.pas" für alle Windows oder "Win32.MyCode.pas" nur für Win32 verwenden. (es sei denn Delphi erstellt selber bereits standardmäßig solche abhängigen Namespaces)

Delphi-Quellcode:

uses MyCode;

wird dann eben als "Win32.MyCode.pas", "OSX.MyCode.pas" usw. ausgewertet, wenn keine "MyCode.pas" gefunden wird.

[Bambini]

Zitat:

Zitat von himitsu (Beitrag 1344017)

du kannst auch den Standard-NameSpace verwenden.
Macht Embarcadero auch so.
Bei VCL-Projekten ist "Vcl" eingetragen und bei den Affen halt "Fmx".
In den Uses steht dann "Forms" und verwendet wird da dann jeweils "Vcl.Forms.pas" oder "Fmx.Forms.pas".

Ja, nur schicker sieht es als Suffix aus.

[Rollo62]

Das kommt ja auch sehr drauf an was du damit machen willst.

Manchmal sind in den sub-units nur einfache Funktionen dahinter.

Man könnte in die sub-units auch die Basisfunktionen einer Basisklasse implementieren, und
von dieser dann im main Unit wieder ableiten, und schon hat man die Platform-Funktionen ausgelagert.

Ich finde auch den FMX.TPlatform-Ansatz generell ganz gut, wie verschiedene Services ausgeklammert werdern,
bin mir aber nicht sicher ob das immer richtig ist.
Z.B. ob ein ständiges Holen der Interfaxce nicht etwas ineffizient ist, wie z.B. Canvas-Routinen,
die ständig aufgerufen werden.

Generell mit RegisterXyz(); und im main unit Interfaces erzeugen, das ist auch OK, aber ich denke
es wird meistens auch im main unit ein allgemeiner Code gebraucht.
Der sollte eben nicht in Sub-Units redundant ausgeklammert werden.

Entkoppeln könnte man aber auch über TMessages, so das die entsprechenden Sub-Module nur über Messaging kommunizieren.

Jedenfalls finde ich das die Entkopplung von der Platform, wie auch immer, viel an Lesbarkeit bringt.
Und vor alem mal eine Wiedervervendung möglich macht.
Wenn man alles in einer Unit mit 100 IDEFs verwurschtelt hat, mal ehrlich, das fasst doch keiner gerne nochmal an.

Von der Verbesserten Testbarkeit kleinerer Module mal ganz zu schweigen.

Aber einen klaren Favoriten habe ich da auch nicht (gibt es wohl auch gar nicht), mich ärgrt nur
das ich meistaus Zeitgründen auch wieder zu den IFDEFs komme,
um das dann später wenn Zeit ist wieder zu entflechten ab einer gewissen Größe.
Also es hängt Alles immer auch vom "Wollen" ab, und da bin ich leider auch immer viel zu willensschwach :stupid:

@Himitzu
Na klar, so etwa

Delphi-Quellcode:

  FMX.MyLibrary.MachWas.Mycode.Win32

Schön aufgeräumte codegruppen finde ich immer gut, aber oft entwickelt sich das erst über die Zeit.
Ich finde der Platform sollte hinten dran sein, ist aber Geschmachssache.


Rollo

[bra]

Es geht ja nicht nur um komplette Routinen, sondern auch um einzelne Teile, wo nur wenige Zeilen innerhalb einer Funktion plattformspezifisch anders sind. Da funktioniert innerhalb der ANDROID-Defines meist überhaupt keine Codeerweiterung mehr, d.h. man programmiert mit einem normalen Editor, was extrem nervig ist.

[himitsu]

Zitat:

Zitat von bra (Beitrag 1344051)

Es geht ja nicht nur um komplette Routinen, sondern auch um einzelne Teile, wo nur wenige Zeilen innerhalb einer Funktion plattformspezifisch anders sind. Da funktioniert innerhalb der ANDROID-Defines meist überhaupt keine Codeerweiterung mehr, d.h. man programmiert mit einem normalen Editor, was extrem nervig ist.

Der Parser/Backgroundcompiler kann ja nicht einfach alle IFDEFs aktiv machen, damit man überall alles hat (ergibt bestimmt im vorhergehenden Code massig Chaos/Konflikte).
Aber für die aktive BuildConfig sollten die DEFINEs müssten ausgewertet werden, damit man im dazu passenden Code auch die nötigen Funktionen (Codevervollständigung usw.) erhalten kann.
Also OSX-Config aktiv, dann sollte sich auch der OSX-Code ordentlich bearbeiten lassen müssen. (währe jedenfalls zu schön)