Fehlende Sprachfeatures

[Stevie]

Da ja seit dem Release von Lazarus 1.0 ein regelrechter Hype losgebrochen ist, stell ich mir die Frage, inwieweit an den gegenüber Delphi (2010 oder neuer) fehlenden Sprachfeatures gearbeitet wird.

Gibt es da einen derzeitigen Stand (wenn ich mich nicht irre, gibt es ja einige Member hier, die diesbzgl aktiv sind)?

Speziell für mich interessant wären Enhanced RTTI und anonyme Methoden.

Zu enhanced RTTI: wäre jetzt schon möglich, eine gewisse Kompatibilität zu erreichen, was die API angeht und sofern benötigte type information vorhanden ist (glaube aber, die ist noch auf dem Stand von Delphi 7? sprich nur published member).

[himitsu]

Die alte RTTI geht nur auf public/publisches Fields/Methodes.
In der neuen erweiterten RTTI sind (falls man es nicht explizit ausschaltet) sogar "private"- und "strict private"-Dinge enthalten.

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1184242)

Die alte RTTI geht nur auf public/publisches Fields/Methodes.
In der neuen erweiterten RTTI sind (falls man es nicht explizit ausschaltet) sogar "private"- und "strict private"-Dinge enthalten.

Du hast gesehen, in welchem Unterforum wir sind, oder?

[himitsu]

Nö :lol:

[Neutral General]

Wobei ich sagen muss, dass mich der Text oben auch irritiert hat und ich deinen Post 3x lesen musste bevor ich gemerkt habe dass es hier nicht um Delphi geht. Mit dem Stichwort "Freepascal" im Titel oder in deinem Ausgangspost gäbe es da wahrscheinlich nicht so viel Verwirrung ;)

[himitsu]

Vielleicht können wir Danel ja dazu überreden, ein paar Unterforen irgendwie hervorzuheben.

Wie wäre es mit Pink als Hintergrundfarbe beim FreePascal?
(oder einem rötlichem "(FreePascal)" hinter der Überschrift jedes Posts)

[JamesTKirk]

Zitat:

Zitat von Stevie (Beitrag 1184237)

Da ja seit dem Release von Lazarus 1.0 ein regelrechter Hype losgebrochen ist, stell ich mir die Frage, inwieweit an den gegenüber Delphi (2010 oder neuer) fehlenden Sprachfeatures gearbeitet wird.

Gibt es da einen derzeitigen Stand (wenn ich mich nicht irre, gibt es ja einige Member hier, die diesbzgl aktiv sind)?

Damit bin wohl (u.a.) ich gemeint. :mrgreen:

Zitat:

Zitat von Stevie

Speziell für mich interessant wären Enhanced RTTI und anonyme Methoden.

Aaaalllso. *Ärmel hochkrämpelt*

Bei Enhanced RTTI und anonymen Methoden gibt es noch nichts im Trunk (also der Entwicklungsversion).

Vor einiger Zeit hat jedoch jemand drittes damit begonnen anonyme Methoden in einem Branch zu implementieren, dessen Aktivitäten sind jedoch wieder eingeschlafen. Vielleicht muss ich ihn mal fragen, ob er noch weitermachen möchte und wenn nicht muss ich selbst mal schauen das fertig zu bekommen.

An der Enhanced RTTI arbeitet zur Zeit noch niemand, wäre jedoch ne Idee, dass ich mal da dran arbeite, sobald ich mit Generics und Helpern halbwegs fertig bin.

Was mich gleich zu weiteren Features bringt:

• Delphi-Quellcode:

  is

  und
  Delphi-Quellcode:

  as

  für Interfaces werden bereits seit mindestens 2.6.0 unterstützt
• ein weiterer FPC Entwickler arbeitet derzeit an Attributen
• in 2.7.1 hat sich (dank mir :D ) vieles in Sachen Generics und deren Kompatibilität zu Delphi getan, einige Sachen fehlen jedoch noch, an denen ich in nächster Zukunft arbeiten werde: Generic Constraints, Generic Functions/Methods (ja, FPC wird auch globale generische Funktionen unterstützen), Nested Generics, Nested Specializations (z.B. TMyList<TMyContainer<String>>), bessere Unterstützung für Inline Specializations (mich grauts bereits davor...)
• class und record helper sind (in 2.6.0) auf dem Stand von Delphi XE2 (da sich bis dahin nicht allzuviel getan hat). Type helper (also die aus Delphi XE3) sind von mir geplant (ich habe bereits eine Proof of Concept Implementierung am Laufen)
• Advanced records sind in 2.6.0 implementiert mit der Ausnahme von Konstruktoren
• der Codepage Aware AnsiString ist in 2.7.1 vorhanden,
  Delphi-Quellcode:

  String

  wurde jedoch noch nicht nach
  Delphi-Quellcode:

  UnicodeString

  geändert (es existiert jedoch ein Modeswitch, mit dem man das machen kann, aber noch ist dessen Verwendung nicht wirklich empfehlenswert...)
• Delphi-Quellcode:

  delay;

  wird auch nicht unterstützt (ich weiß aber auch niemanden, der aktiv daran arbeitet oder es sich wünscht)

Das müsste das insoweit zusammen fassen.

Zitat:

Zitat von Stevie

Zu enhanced RTTI: wäre jetzt schon möglich, eine gewisse Kompatibilität zu erreichen, was die API angeht und sofern benötigte type information vorhanden ist (glaube aber, die ist noch auf dem Stand von Delphi 7? sprich nur published member).

Die Unit RTTI hat das Problem, dass sie auch teilweise auf Generic Methods setzt, welche ich wie geschrieben jedoch erst noch implementieren muss. Außerdem dürfte die Implementierung der RTTI Daten an sich nicht sooooo schwierig sein. Es muss halt nur mal einer machen. ;)

Gruß,
Sven

[Stevie]

Danke für deine ausführliche Erläuterungen zum derzeitigen Stand.

Speziell zur RTTI stelle ich mir dann die Frage, wie es mit den Stellen aussehen wird, bei denen man um asm nicht mehr herum kommt bzgl der verschiedenen Targets.

Eine weitere Sache, die für mich interessant ist (im Hinblick auf eine FPC kompatible DSharp Version), inwieweit die API dann kompatibel sein wird. Könnt ihr euch die bei Delphi abschauen (Lizenz?) oder wie läuft das dann? Was ich auf keinen Fall machen werde, ist tonnenweise ifdefs in meinem Code verstreuen, um FPC zu unterstützen.

[JamesTKirk]

Zitat:

Zitat von Stevie (Beitrag 1184312)

Speziell zur RTTI stelle ich mir dann die Frage, wie es mit den Stellen aussehen wird, bei denen man um asm nicht mehr herum kommt bzgl der verschiedenen Targets.

Wie genau meinst du das? Die RTTI Funktionalität besteht doch im Endeffekt nur aus High Level Funktionen/Methoden? Intern wird natürlich - falls nötig - für die Plattform passender Assemblercode (zum Beispiel aller Wahrscheinlichkeit nach für

Delphi-Quellcode:

RTTI.Invoke

) verwendet, aber das sollte den normalen Benutzer nicht wirklich tangieren...

Zitat:

Zitat von Stevie

Eine weitere Sache, die für mich interessant ist (im Hinblick auf eine FPC kompatible DSharp Version), inwieweit die API dann kompatibel sein wird. Könnt ihr euch die bei Delphi abschauen (Lizenz?) oder wie läuft das dann? Was ich auf keinen Fall machen werde, ist tonnenweise ifdefs in meinem Code verstreuen, um FPC zu unterstützen.

Wir orientieren uns was Schnittstellen angeht an der Hilfe von Delphi (zum Beispiel die Delphi Referenz im Wiki von Embarcadero). Hiermit stellen wir sicher, dass einerseits so gut wie möglich Delphi Kompatibilität besteht und wir andererseits nicht Embarcaderos Copyright verletzen (Schnittstellen allein fallen ja nicht unters Copyright). Ich selbst verwende zum Beispiel genau aus diesem Grund die XE Starter für Tests, damit ich nicht in die Verführung komme in die Implementierung der RTL zu schauen. ;) Die Korrektheit der Implementierung wird dann durch Tests sichergestellt, welche sowohl unter Delphi als auch unter FPC kompilieren/laufen können. Die Kompatibilät zu Delphi wird nur in Ausnahmefällen (zum Beispiel historische Gründe oder Multiplattformfähigkeit) gebrochen.

Gruß,
Sven

[Stevie]

Zitat:

Zitat von JamesTKirk (Beitrag 1184320)

Wie genau meinst du das? Die RTTI Funktionalität besteht doch im Endeffekt nur aus High Level Funktionen/Methoden? Intern wird natürlich - falls nötig - für die Plattform passender Assemblercode (zum Beispiel aller Wahrscheinlichkeit nach für

Delphi-Quellcode:

RTTI.Invoke

) verwendet, aber das sollte den normalen Benutzer nicht wirklich tangieren...

Fraglich ist halt, ob gleich jede Plattform supported wird. Außerdem gibt es nach wie vor einige größere Unterschiede, wenn man sich in solchen Bereichen wie RTTI bewegt (hab z.B. nicht die ObjAuto.pas in FPC gefunden).

[JamesTKirk]

Zitat:

Zitat von Stevie (Beitrag 1184340)

Zitat:

Zitat von JamesTKirk (Beitrag 1184320)

Wie genau meinst du das? Die RTTI Funktionalität besteht doch im Endeffekt nur aus High Level Funktionen/Methoden? Intern wird natürlich - falls nötig - für die Plattform passender Assemblercode (zum Beispiel aller Wahrscheinlichkeit nach für

Delphi-Quellcode:

RTTI.Invoke

) verwendet, aber das sollte den normalen Benutzer nicht wirklich tangieren...

Fraglich ist halt, ob gleich jede Plattform supported wird. Außerdem gibt es nach wie vor einige größere Unterschiede, wenn man sich in solchen Bereichen wie RTTI bewegt (hab z.B. nicht die ObjAuto.pas in FPC gefunden).

Das Generieren der RTTI Daten ist ziemlich plattformunabhängig, bzw. wird eh bereits passend für die "normale" RTTI gemacht, also muss das nur entsprechend angepasst werden. Der Rest ist dann einfach passend auf die Daten zuzugreifen. So viel Assembler dürfte da am Ende gar nicht nötig sein (ich glaub die aktuelle RTTI braucht sogar gar kein Assembler).

Bei den Punkten, bei denen Assembler nötig wird (also hier vor allem wieder

Delphi-Quellcode:

RTTI.Invoke

), kann es natürlich sein, dass zuerst nur die Hauptplatformen (sprich x86, x86_64 (evtl. mit extra Code für Win64) und ARM) drankommen, aber die anderen sollten dann früher oder später folgen. Hier ist halt vor allem das Problem, dass nicht jeder gleich firm mit den verschiedenen Prozessoren ist. Ich selbst hätte zum Beispiel kaum Probleme mit x86 und x86_64, aber bereits mit ARM schaut die Sache ganz anders aus, von Sparc, PowerPC(64), MIPS(64) oder AVR ganz zu schweigen. Das müsste dann also jemand anderes machen (unter der Annahme, dass ich da was implementiere).

Was ist denn diese ominöse

Delphi-Quellcode:

ObjAuto

-Unit? Die höre ich heute zum ersten Mal...

Edit: Ok, ich hab nachgeschaut. Die

Delphi-Quellcode:

ObjAuto

-Unit fällt für mich in das gleiche Säckerl wie Extended RTTI und Attribute. Alles Features, die erst mit Delphi 2009 und neuer hinzugekommen sind. Sie stehen auf der Agenda, aktuell arbeitet jedoch (meist) keiner dran.

Gruß,
Sven

[Stevie]

Zitat:

Zitat von JamesTKirk (Beitrag 1184348)

Edit: Ok, ich hab nachgeschaut. Die

Delphi-Quellcode:

ObjAuto

-Unit fällt für mich in das gleiche Säckerl wie Extended RTTI und Attribute. Alles Features, die erst mit Delphi 2009 und neuer hinzugekommen sind. Sie stehen auf der Agenda, aktuell arbeitet jedoch (meist) keiner dran.

ObjAuto.pas gibt es schon seit mindestens Delphi 7.

[JamesTKirk]

Zitat:

Zitat von Stevie (Beitrag 1184349)

Zitat:

Zitat von JamesTKirk (Beitrag 1184348)

Edit: Ok, ich hab nachgeschaut. Die

Delphi-Quellcode:

ObjAuto

-Unit fällt für mich in das gleiche Säckerl wie Extended RTTI und Attribute. Alles Features, die erst mit Delphi 2009 und neuer hinzugekommen sind. Sie stehen auf der Agenda, aktuell arbeitet jedoch (meist) keiner dran.

ObjAuto.pas gibt es schon seit mindestens Delphi 7.

Delphi 6 scheint sie zumindest noch nicht zu enthalten (auch wenn hier eine ObjAuto.pas von Embarcadero zur Verfügung gestellt wird, die auch unter Delphi 6 funktionieren soll).

Die ganze Funktionalität scheint im Zusammenhang mit

Delphi-Quellcode:

{$methodinfo ...}

(siehe hier) zu stehen, welches von FPC auch nicht unterstützt wird.

Allgemein scheint diese Funktionalität nicht ganz so häufig verwendet zu werden, da ich wie gesagt heute zum ersten Mal davon gehört habe und ich auch bei den FPC Mailing Listen bisher noch nichts dazu gelesen habe. Dies bedeutet jedoch nicht, dass wir dafür keine Unterstützung einbauen würden ;) Vielleicht kann man das ganze auch gleich kombinieren, so dass die Extended RTTI und die ObjAuto auf die selben Daten zugreifen...

Gruß,
Sven

[Stevie]

Ich meine, mich zu erinnern, dass das damals für DataSnap benötigt wurde.

[Stevie]

Knapp eineinhalb Jahre sind nun vergangen nach meiner letzten Anfrage und ich wollte mal nach dem aktuellen Stand von FPC fragen (Lazarus gurkt ja immernoch auf 2.6.2 rum)

[mjustin]

Zitat:

Zitat von Stevie (Beitrag 1243899)

Knapp eineinhalb Jahre sind nun vergangen nach meiner letzten Anfrage und ich wollte mal nach dem aktuellen Stand von FPC fragen (Lazarus gurkt ja immernoch auf 2.6.2 rum)

Lazarus-trunk ist auf 2.7.1 (trunk)

Zum Ausprobieren: http://www.delphipraxis.net/177822-fpc-crosswin.html

[Stevie]

Zitat:

Zitat von mjustin (Beitrag 1243902)

Lazarus-trunk ist auf 2.7.1 (trunk)

Ja, ok, Lazarus mit 2.7.1 gab's schon vor über nem Jahr - ich bezog mich auf release Versionen :)
Die ungeraden (also auch FPC 2.7.1) sind ja keine Release Versionen, soweit ich weiß.
Hieße, die nächste Lazarus Release Version wäre mit FPC 2.8?

Bis dahin wird vermutlich XE mit ner zweistelligen Nummer released worden sein.

Ungeachtet release oder nicht warte ich nach wie vor auf enhanced RTTI, funktionierende Generics und anonyme Methoden in FPC.
Von diesen drei Dingen weiß ich nur bei den Generics, dass daran gearbeitet wird.

[JamesTKirk]

In den letzten Monaten ist zumindest bei mir nicht allzuviel voran gegangen, da ich noch an meiner Masterarbeit arbeite.

Dennoch hier ein kleiner Überblick, was denn so ansteht:
- bei mir lokal habe ich einen Branch, in dem zumindest im ObjFPC-Modus generische Funktionen/Prozeduren (aber noch keine Methoden :P ) funktionieren
- auch bei mir lokal arbeite ich an Packages, was mir jedoch noch ein bisschen Kopfschmerzen bereitet
- die ersten Schritte in Richtung Extended RTTI finden zur Zeit von einem anderen Entwickler im Zusammenhang mit Attributen statt, dessen Branch im Großen und Ganzen fertig für nen Merge ist (allerdings werden dort aktuell nur Klassenattribute unterstützt)
- ein auswärtiger Entwickler hat an anonymen Funktionen gearbeitet (scheinbar für eine Studienarbeit), aber ich habe in letzter Zeit nichts mehr von ihm gehört (wenn ich fertig bin mit der MA, dann werd ich da mal nachhaken und notfalls dessen bisherige Arbeit selbst fortführen)
- außerdem plane ich zur Zeit eine ARC-Implementierung, die jedoch im Gegensatz zu der des LLVM-Delphi-Compilers kompatibel zu bisherigen Code sein soll (soll heißen: neuer Code profitiert davon, alter Code wird nicht davon beeinträchtigt)

Ich hoffe das gibt dir einen kleinen Einblick. :)

Gruß,
Sven

[Stevie]

Vielen Dank für den Statusbericht :)