Warum kennt Delphi eigentlich keine Makros?

[himitsu]

Indirekt kann man sowas wie unparametrisierte Makros schon verwenden.
Es ist nur etwas umständlich/häßlich/unübersichtlich/unpraktisch.

Zitat von Datei 'paramdef' oder halt 'paramdef.inc':

{$IFDEF XYZ_PARAMS}; xyz: Integer{$ENDIF}

Zitat von Datei 'param':

{$IFDEF XYZ_PARAMS}xyz{$ENDIF}

Delphi-Quellcode:

{$DEFINE XYZ_PARAMS}

procedure Test(abc: string {$I paramdef});
begin
  OtherProc(abc {$I param});
  Länger(abc {$INCLUDE param});
end;

Die selbe Technik, nur eben mit einer anderen Quelle und etwas mit Parameter aufgemotzt, wäre nötig.
(statt von Datei, aus einer Liste, welche über die DEFINEMACRO-Dinger befüllt wird)

[jaenicke]

Also ich persönlich finde es schon in C++ schrecklich unübersichtlich. Ich hoffe, dass das niemals in Delphi kommt...

[Sherlock]

Schließe mich jaenicke an und erhöhe um ein gepflegtes: "wozu soll das gut sein?"

Sherlock

[mkinzler]

Um Delphicode ähnlich unleserlich zu machen wie C++-Code.

[himitsu]

Zitat von jaenicke:

Also ich persönlich finde es schon in C++ schrecklich unübersichtlich.

So wie es in C++ ist, finde ich es auch schrecklich. Das Makro sieht ha wie eine normale Variable/Typ/Konstante aus
Aber als "erkennbarer" Compiler-Befehl find ich es doch ganz OK.

Zitat von mkinzler:

Um Delphicode ähnlich unleserlich zu machen wie C++-Code.

Das geht auch jetzt schon.
Ich find es leider nicht, aber ich hatte hier dieses/letzt Jahr doch mal einen Einzeiler gepostet, welcher ein "step" in die Forschleife baut.
Schön mit Gernics und Anonymen verschnuddelt ... ihr kennt doch diese einzeiligen C-Codes, wo tausende Rechenoperationen "verschlüsselt" sind.

Es geht mir halt um eine Headerübersetzung.
Diese wird in Zukunft öfters mal angepaßt werden müssen und da fände ich es praktisch, daß es halbwegs wie im Original aussieht.
Ich hab es jetzt erstmal mit den Include-Dateien gelöst, aber leider kann Delphi nachwievor nicht ordentlich damit arbeiten.

Debuggen ist grausam und bei Fehlern muß man erstml umständlich suchen, weil bei einem Fehler in der IncludeDatei, bzw. wenn der Fehler eigentlich in der PAS beginnt, aber in der INC aufrtitt, dann zeigt der Debugger, aber vorallem der Compiler nicht an, aus welcher Datei der Aufruf (die Einbindung) kam.

[stahli]

Dein Beispiel mit den Macro-Schaltern finde ich auch eher verwirrend (aber auf sowas stehst Du ja immer ).

Deine Problemschilderung mit den Includes kann ich aber gut nachvollziehen und verzichte deswegen meist darauf.

Alternativ zu Macros (wie ich das verstanden habe) würde ich mir andere Lösungen wünschen:

Eine Überarbeitung des Quelltexteditors wäre in dem Zusammanhang nochmal überdenkenswert. Wir hatten das schon mal angesprochen in Bezug auf mehrere Editorfenster...

Grundsätzlich wäre es nett, wenn eine Unit nicht generell stur komplett im Editor stehen würde, sondern die einzelnen Klassen, Funktionen und Methoden (auf Wunsch) in eigenen Editoren bearbeitet werden könnten. Wenn ich eine Funktion ausfülle, dann brauche ich ja nicht die gesamte Unit im Editor sehen, sondern lediglich die Bereiche, auf die ich von der aktuellen Stelle aus zugreifen kann. Also ich würde gern im Interface-Teil eine Funktion definieren und das Ausfüllen dann (z.B. nach Doppelklick) optional in einem eigenen Editor erledigen.
Darüber hinaus könnte auch ein Include-Code real im Code eingebunden und dargestellt werden (vielleicht farbig hinterlegt) und Änderungen würden (automatisch im Hintergrund in die externe Datei gespeichert und) in allen anderen Units übernommen, wenn man zu einer solchen wechselt.

Ich könnte mir da ein paar hilfreiche Dinge vorstellen. Ob Emba sich aber die Zeit für solchen Kleinkram nimmt...
Das Beispiel Debugger Canvas trifft es nicht ganz, zeigt aber, dass man nicht zwangsläufig nur eine komplette pas editieren muss.

[jaenicke]

Zitat von stahli:

Eine Überarbeitung des Quelltexteditors wäre in dem Zusammanhang nochmal überdenkenswert. Wir hatten das schon mal angesprochen in Bezug auf mehrere Editorfenster...

Das Problem ist bei den ausgedockten separaten Editorfenstern bei Delphi XE vor allem, dass deren Positionen nicht ordentlich gespeichert werden. Dadurch schwirren die insbesondere bei mehreren Bildschirmen sinnlos über den Bildschirm.
Das ist dann fast so schlimm wie bei Delphi 7 und früher...

[mkinzler]

Du könntest die Klassen auch in Regionen packen und dann nur die jeweils "richtige" eingeblendet lassen

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