Warum kennt Delphi eigentlich keine Makros?

[D-User]

Zitat von himitsu:

... würde man das Makro dann direkt im QuellCode ändern (nicht nur wirklich "temporär", im Hintergrund, beim Kompilieren)
und wenn dabei was schief geht, dann steht der Quellcode danach schief.
...

könnte man das nicht konstruktiv leicht so lösen, indem man in die Projektgruppe
ein Compile-Projekt mit aufnimmt, jede makroverseuchte Datei des ursprünglichen Projektes bekommt dort ihr Pendant mit gleichem Namen, aber Suffix, z.B. _C, und dann wird in diese _C's expandiert und dieses "expandierte Projekt" schlussendlich compiliert?

(OK, ich gebs zu, man muss dann immer eine solche Prj-Gruppe bevorraten, aber
das halt ich für machbar wenn man schwer mit Makros arbeiten muss)
(wär doch ne schöne Aufgabe für nen GExperts-Button, der das dann alles automat. erledigt )

[D-User]

Zitat von Dejan Vu:

Was war nochmal der Vorteil von Makros ggü (inline)Funktionen?

man stelle sich vor man will seinen eigenen völlig anderen Syntax einführen...

[himitsu]

Einfache Markos würden mir ja auch reichen, wobei "einfach" bei mir eher nur als "einzeilig" definiert ist, wobei man notfalls auch mehrere Befehle in eine machen könnte und "mehrzeiliges" notfalls als Include-Datei implementiert,
womit der Compiler und vorallem der Debugger problemlos klar kommen sollte.

Nja, ich bin aktuell dabei mich nochmal durch die OpenToolsAPI zu kämpfen.
Mal sehn, ob dafür eventuell sich doch irgendwie ein unschöner Weg bietet.
Aber zuletzt gab es im alten Compiler (bis Delphi 7) mal jemanden, welcher es dort schaffte sich halbwegs ordentlich in den Compile-Vorganz reinzuhacken.


PS: Über Markos könnte man eventuell sogar bedingt sowas wie eine Mehrfachvererbung für Klassen realisieren, was man bisher aber auch schon über zwei Includedateien machen könnte.
> gleiche Funktionen "nachträglich" in meherere Klassen integrieren, ähnlich den Class.Helpern, nur eben richtig rein, in jeweils eine Klassenableitung.

[Dejan Vu]

Zitat von D-User:

Zitat von Dejan Vu:

Was war nochmal der Vorteil von Makros ggü (inline)Funktionen?

man stelle sich vor man will seinen eigenen völlig anderen Syntax einführen...

Man stelle ich vor, das man damit ziemlich einsam ist.

Ich meinte 'Vorteile'. Nicht 'Spielereien'

PS: Mehrfachvererbung von Klassen ist out und gefährlich.

[mquadrat]

Also ich kann da auch beim besten Willen keinen Vorteil entdecken.

[mkinzler]

Zitat von mquadrat:

Also ich kann da auch beim besten Willen keinen Vorteil entdecken.

Warum ist doch eine hervorragende Möglichkeit, den Code noch unleserlicher zu gestalten ...

[himitsu]

Wobei UNLESERLICH nicht für alles gilt.

Die __LINE__ und __FILE__-Makros vom PHP wären eigentlich ganz nett, vorallem für den Code der Fehlerbehandlung und das Logging.


Und was das "Mehrfachvererben" ist vielleicht ein zu großes Wort für:
Ich hab mehrere Klassen ala TEdit, TButton usw. und mächte denen allen ein zusätzliches "gleiches" Property/Funktion verpassen,
wobei man das hier nunmal nicht in einen gemeinsamem Vorfahren reinmachen kann, sondern nur in einen jeweils "gleichartig" erweiterten Nachfahren.
Hierbei ist das Makro dann ein an einer Stelle notierter Copy&Paste-Code, den man sonst überall reinkopieren würde.

[Mikkey]

Zitat von himitsu:

Wobei UNLESERLICH nicht für alles gilt.

Bei jeder Sprache und Spracherweiterung gibt es Leute, die schlechte lesbaren Code schreiben und andere die so etwas nicht schaffen

Zitat:

Die __LINE__ und __FILE__-Makros vom PHP wären eigentlich ganz nett, vorallem für den Code der Fehlerbehandlung und das Logging.

Ergänze: __FUNCTION__ zumindest in C gibt es die drei.

Zitat:

Und was das "Mehrfachvererben" ist vielleicht ein zu großes Wort für:
Ich hab mehrere Klassen ala TEdit, TButton usw. und mächte denen allen ein zusätzliches "gleiches" Property/Funktion verpassen,
wobei man das hier nunmal nicht in einen gemeinsamem Vorfahren reinmachen kann, sondern nur in einen jeweils "gleichartig" erweiterten Nachfahren.
Hierbei ist das Makro dann ein an einer Stelle notierter Copy&Paste-Code, den man sonst überall reinkopieren würde.

So etwas müsste sich doch mit Generics á la

Code:

TControlExtended<TEdit>

machen lassen. Ich habe keine passende delphiversion um das auszuprobieren, aber im C# kann man das AFAIR machen.

[himitsu]

Nein, denn in Generics gibt es Einwas, das man nicht generisch machen kann und das ist der Vorfahre, da die Generics ebenfalls immer nur eine Einfachvererbung können.

Das geht nicht und das wäre dafür dann nötig

Delphi-Quellcode:

type
  TMyClass<TVorfahr> = class(TVorfahr)
  end;

Sowas geht zwar

Delphi-Quellcode:

type
  TMyClass<TAndereClasse> = class
  private
    FGekapselt: TAndereClasse;
  published
    property Gekapselt: TAndereClasse read FGekapselt;
  end;

Aber grade in der VCL ist das auch nicht so gut, außer du fängst an nochmal alles z.B. in unsichtbaren TPanels zu kapseln und findest dann alle Property versteckt als Unterproperty in dem Gekapselt, da die Generics Diese nicht alle nach oben durchreichen kann, weil sie ja überall unterschiedlich sind, oder du schreibst die Weiterleitungen wieder manuell überall rein.

[Mikkey]

Zitat von himitsu:

Nein, denn in Generics gibt es Einwas, das man nicht generisch machen kann und das ist der Vorfahre, da die Generics ebenfalls immer nur eine Einfachvererbung können.

Das geht nicht und das wäre dafür dann nötig

Delphi-Quellcode:

type
  TMyClass<TVorfahr> = class(TVorfahr)
  end;

Dann würde ich mir eher wünschen, dass das ginge. Mit Mehrfachvererbung hat das ja nichts zu tun, weil ich immer noch eine eindeutige Ableitungskette TObject->TComponent->...->TEdit->TGen<TEdit> habe.

Übrigens kann man sich für's Loggen einen Präprozessor schreiben, der geschriebene Aufrufe

Log('blabla'); in Aufrufe

Log('blabla', 'u_TestUnit', 234, 'TestFunction'); übersetzt bzw. die bereits vorhandenen weiteren Parameter aktualisiert.