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.

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

[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

[D-User]

Zitat von himitsu:

Voll blöd, daß man immernoch nicht wieder selber einen Precompiler reinhängen kann, um das selbst zu implementieren.

Hilft denn da nicht zwanglos das Build-Ereignis "Pre-Build" zum rel.leicht selber abhandeln? (Projekt Optionen "Build-Ereignisse")

[himitsu]

Jain.

Erstmal dreht dann der Debugger durch und dann 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.

PS: Ich hab 'ne Option aktiv "Speichern beim Kompilieren", falls die IDE abkratzt, damit dann nicht eventuell was weg ist.
Tja, dabei würden dann auch die ersetzten Makros gespeichert.



Ach ja, im Post-Build müssten die ersetzten Makros wieder zurückgesetzt werden, nur gibt es da das Problem, daß das Post-Build z.B. bei einem Fehler (Compile-Error) nicht ausgeführt wird und dann die Markos ebenfalls noch ersetzt bleiben würden.



Fazit: Egal wie man es dreht, irgendwo ist immer alles kaputt (dauerhaft oder gar nur halb Ersetzt).

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