Warum kennt Delphi eigentlich immernoch keine Makros?
Vorallem beim Übersetzen von C-Headern wäre sowas einfach zu praktisch.


So schwer sollte das doch nicht zu implementieren sein?
Und es, bezüglich der Delphi-Language, kompatibel zu implementieren ist och nicht unmöglich.

zusammenfalten · markieren

Delphi-Quellcode:

{$DEFINEMACRO param '; xyz: Integer'}
{$DEFINEMACRO param_x ', xyz'}
{$DEFINEMACRO say 'Beep; ShowMessage(''Hello %1'');' string}
{$DEFINEMACRO msg '(''%3'' + Format('' %%s %%d'', [''%1'', %2]))' string integer string}

procedure Test(abc: string {$MACRO param}); // procedure Test(abc: string ; xyz: Integer);
begin
  {$IFMACRO param}
    ShowMessage(IntToStr(xyz));
  {$ENDIF}
  OtherProc(abc {$MACRO param_x});

  {$MACRO param 'World'}  // Beep; ShowMessage('Hello World');

  ShowMessage{$MACRO msg 'World' 123 'Hello'}; // ShowMessage('Hello' + Format(' %%s %%d', ['World', 123]));
end;

Der Compiler braucht das doch nur beim Parsen im Code zu ersetzen und danach zu interpretieren.

Natürlich sollte er alle Zeilenumbrüche in den Macros ignorieren (durch Leerzeichen zu ersetzen) ... dann dürfte auch der Debugger keine Probleme bekommen, da sich die Zeilenpositionen nicht verändern.


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

Der Free Pascal Compiler kennt Makros in einfacher Form:

markieren

Delphi-Quellcode:

{$macros on}
{$define blabla:=tudiesunddas(xyz);undnochwas();xyz:=123}

...

blabla; // tudiesunddas(xyz);undnochwas();xyz:=123;

Bloss Parameter sind noch nicht unterstuetzt. Aber parametrisierte Makros sind doch quasi nichts gross anderes als Inline-Routinen.

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}

markieren

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)

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

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

Sherlock

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

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.

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.

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

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