Warum kennt Delphi eigentlich keine Makros?

[implementation]

Zitat von himitsu:

So wie es in C++ ist, finde ich es auch schrecklich. Das Makro sieht ha wie eine normale Variable/Typ/Konstante aus

Hae? Makros erkennt man doch sehr gut, an der Grossschreibung. Und wenn Typen oder Konstanten komplett grossgeschrieben werden, dann liegt das daran, dass es ein Makro ist (bzw. typedef, aber wo ist schon der Unterschied?)

[shmia]

Es gibt ja auch Lisp-Programmierer, die sind richtig hardcore drauf, denn Makros werden in Lisp selbst in der Programmiersprache Lisp programmiert.
Das wäre ungefähr so wie wenn der Sourcecode zuerst mit einem Pascal-Interpreter verarbeitet wird, bevor der Compiler ran darf.

Hier mal als kleine verrückte Idee.
Alles was zwischen #beginmacro und #endmacro liegt sind Anweisungen an den Pascal-Interpreter:

Delphi-Quellcode:

#beginmacro
function Forever():string;  // neues Makro
begin
  result := 'while(True) do';
end;

function Sondersoftware(veriante:integer):string;
begin
  case veriante of
    1: result := 'x * x / 2.0';
    2: result := '(x * x / 2.0) + 0.0001'; 
  else
     raise Exception.Create('ungültige veriante von #Sondersoftware()');  // erzeugt Compilerfehler
  end;
end;

function RepeatInline(const Befehl:string; Anzahl:Integer):string;
begin
   result := '';
   while (Anzahl > 0) do
     Result := Result + Befehl + ';'+#13#10;
end;
#endmacro

// Beispiel
RepeatInline('ShowMessage(''Hello World'')', 5);

Aber man muss zugeben: Lisp ist irgendwie besser für Makros geeignet als Pascal/Delphi.

[himitsu]

Nja, aus der WinAPI kennt man auch makros, welche eigentlich mehr funktionen sind, außer daß sie quasi im Compiler ausgeführt aufgelöst werden.

Bei ErrorCodes oder z.B. bei dem Wert für IOCTL_IDE_PASS_THROUGH.

In Delphi ist sowas einfach nicht möglich.

Code:

#define CTL_CODE(DeviceType, Function, Method, Access) (
  ((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)
)

# define IOCTL_ATA_PASS_THROUGH  CTL_CODE(IOCTL_SCSI_BASE, 0x040B, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)

Als Funktion kann man es nicht für Konstanten verwenden:

Delphi-Quellcode:

function CTL_CODE(DeviceType, _Function, Method, Access: Cardinal): Cardinal;
begin
  Result := (DeviceType shl 16) or (Access Shl 14) or (_Function shl 2) or (Method);
end;

Flag:=CTL_CODE(IOCTL_SCSI_BASE, $040B , METHOD_BUFFERED, (FILE_READ_ACCESS or FILE_WRITE_ACCESS));

Oder man macht es so, bzw. rechnet den Wert gleich aus.

Delphi-Quellcode:

const
  IOCTL_ATA_PASS_THROUGH= (IOCTL_SCSI_BASE shl 16) or ((FILE_READ_ACCESS or FILE_WRITE_ACCESS) shl 14) or ($040B shl 2) or (METHOD_BUFFERED);

Nahezu alle Header lassen sich nach C und Co. übersetzen ... nur Andersrum geht es meistens nicht.

[implementation]

Zitat von shmia:

Es gibt ja auch Lisp-Programmierer, die sind richtig hardcore drauf, denn Makros werden in Lisp selbst in der Programmiersprache Lisp programmiert.
Das wäre ungefähr so wie wenn der Sourcecode zuerst mit einem Pascal-Interpreter verarbeitet wird, bevor der Compiler ran darf.

Eines der Dinge, die Lisp so geil und genial machen, dass schon historisch bedeutsame Betriebssysteme darin geschrieben und darueber bedient wurden

[Elvis]

Macros sind normalerweise der Tod von richtig gutem Tools support (á la Resharper oder IntelliJ).
Es macht IMO mehr Sinn pure & deterministische Funktionen einzuführen.
Also Funktionen ohne Nebeneffekte, die bei gleichem Input den gleichen Output liefern.
Dann kann der Compiler sowas für Release builds auflösen.
Und nebenbei ist sowas sehr beruhigend wenn man sehr viel Threading nutzt.


Macros sind IMO eine kurzsichtige, billige Lösung, die einem langfristig die Sprache versauen.

[himitsu]

Delphi is ja angeblich eh schon tot ... da kommt's darauf nun och nimmer an.

[JamesTKirk]

Zitat von implementation:

Zitat von himitsu:

So wie es in C++ ist, finde ich es auch schrecklich. Das Makro sieht ha wie eine normale Variable/Typ/Konstante aus

Hae? Makros erkennt man doch sehr gut, an der Grossschreibung. Und wenn Typen oder Konstanten komplett grossgeschrieben werden, dann liegt das daran, dass es ein Makro ist (bzw. typedef, aber wo ist schon der Unterschied?)

Das ist aber nur reine Konvention. Keiner hält dich davon ab Makros in lowercase oder CamelCase zu definieren und manche tun das dann auch...

Ich bin übrigens froh, dass FPC nur einfache Makros unterstützt. Was die Leute allein schon damit anstellen (abgesehen von den wenigen nützlichen Punkten).

Gruß,
Sven

[Dejan Vu]

Was war nochmal der Vorteil von Makros ggü (inline)Funktionen?
Und wo sind Makros sinnvoll, wenn man die Grundgesetze der OOP-Softwareentwicklung eingehalten hat?

Früher hab ich mich auch oft gefragt, wieso das mit den Makros nicht geht. Aber in den letzten 10 Jahren eigentlich nicht mehr. Vermutlich liegt das daran, das ich eingerostete Gedanken habe und mich in ausgetrampelten Pfaden bewege.

[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.