Abkürzungen für RTL-Funktionen möglich?

[Harry Stahl]

Ist es eigentlich irgendwie möglich, dem Compiler irgendwelche selbst definierten Abkürzungen (Alias) für lange Funktionsnamen beizubringen?

Mich ärgern so Sachen wie

IncludeTrailingPathDelimiter

oder auch nur ExtractFileName.

Es macht die Zeilen lang und versperrt die Sicht auf eigentliche Funktionalität.

So könnte man Abkürzungen definieren etwa wie EFN (für ExtractFilename ) oder (ITPD)

Bin mir selber nicht ganz sicher, ob das sinnvoll wäre, aber mich würde vor allem interessieren, ob das technisch möglich wäre.

[Stevie]

Klingt irgendwie nach einem XY-Problem.

Zitat:

Es macht die Zeilen lang und versperrt die Sicht auf eigentliche Funktionalität.

Deutet für mich auf sowieso unübersichtlichen Code hin, in dem nicht nur bisschen Dateipfade oder so zusammengetüftelt werden sondern noch anderes Zeugs.
Ansonsten könnt man die eigentliche Funktionalität nämlich am Methodennamen ablesen.

Stichwort: Single Level of Abstraction

[himitsu]

Für Typen kann man Aliase erstellen,
bei Variablen kann man sie überdecken (absolute),
aber für Funktionen kann man nur pointern oder inlinen.

Nur für Interfaces kann man bei der Implementation eine "Umleitung" auf andere Methodennamen definieren.

Für verschobene/zentralisierte Funktionen hatte ich mir aber auch schon ein/zwei Mal eine Alias-Behandlung oder Umleitung gewünscht.
z.B. in der alten Unit weiterhin den Aufruf im Interface, aber die Implementierung in der neuen Unit. (ohne das durch eine neue Inline-Methode schieben zu müssen, was z.B. bei Array-Property oftmals sich nicht inlinen lässt)

Delphi-Quellcode:

var kurz: procedure(....);

kurz := @gaaaaaaaaaaanzlang;

Die Variablen kann man auch hinter einem readonly Property oder eventuell auch hinter einer writeable Konstante verstecken.

Delphi-Quellcode:

procedure kurz(...); inline;
begin
  gaaaaaaaaaaanzlang(...);
end;

[Harry Stahl]

@ Stevie: Nö, weder XY-Problem, noch Single Level ob abstraction.

Während sich das XY-Problem ja auf den Fragesteller bezieht, wie nennt man es eigentlich, wenn der Antwortende nicht auf die eigentliche Frage eingeht (technische Machbarkeit), sondern statt dessen Vermutungen über Intentionen des Fragestellers oder gegebene Umstände ("sowieso unübersichtlicher Code") anstellt?:wink:

[Schokohase]

@Harry

Du programmierst doch nicht erst seit gestern und du hast bestimmt schon mal eine

Delphi-Quellcode:

procedure

oder

Delphi-Quellcode:

function

geschrieben.

Die Lösung ist so naheliegend (siehe himitsu), dass man echt ins Grübeln kommt, was du eigentlich wirklich fragen willst.

Wenn du nur wissen willst, wie man eine

Delphi-Quellcode:

procedure

oder

Delphi-Quellcode:

function

mit einem kurzen Namen schreibt, die dann eine

Delphi-Quellcode:

procedure

oder

Delphi-Quellcode:

function

mit langem Namen aufruft, dann kann ich irgendwie nur ungläubig mit dem Kopfe schütteln

[Harry Stahl]

@Schokohase: Hast Du die Frage genau gelesen?

Ich habe gefragt:

"Ist es eigentlich irgendwie möglich, dem Compiler irgendwelche selbst definierten Abkürzungen (Alias) für lange Funktionsnamen beizubringen?"

Und: Nicht für eigene, sondern für RTL-Funktionen.

Ich wollte da keine Umwege über Pointer oder Aufruf von anderen Funktionen gehen.

Es geht doch z.B.

Type
str = string;

Daher fragte ich mich, ob es so etwas ähnliches nicht auch für Funktionen gibt. Es geht also eher um eine Art Makro-Funktionalität.

Und nein, ich bin mir nicht zu schade, um im Zweifel auch mal eine Frage zu stellen, wo jemand meinen könnte, den Kopf schütteln zu müssen.

Eine alte chinesische Weisheit sagt da:

Wer fragt, ist vielleicht ein Narr für fünf Minuten. Wer nicht fragt, bleibt ein Narr für immer.

[Schokohase]

Wenn du mir noch erklären könntest, wodurch sich die RTL Funktionen technisch von den eigenen Funktionen unterscheiden?

Mir ist da nämlich kein technischer Unterschied bekannt. (ja, werden mitgeliefert, sind vorkompiliert, ... alles eher organisatorischer Krams) oder kannst du an dem Code erkennen ob diese nun RTL oder eigen ist?

Zur Frage selber:

Einen Type-Alias gibt es.
Einen procedure/function Alias gibt es nicht.

Das was im weitesten Sinne dem nahe kommen würde, ist das, was man bei einem Interface machen kann.

Delphi-Quellcode:

type
  IFoo = interface
    procedure DoFoo();
  end;

  TFooImplementer = class( TInterfacedObject, IFoo )
    procedure IrgenEinName();
    procedure IFoo.DoFoo = IrgendEinName;
  end;

procedure TFooImplementer.IrgendEinName();
begin
end;

[Harry Stahl]

Der Unterschied zwischen RTL-Funktionen und meinen ist ganz einfach: Meine eigenen Funktionen kann ich umbenennen und im Zweifel einen kurzen aber prägnanten Namen geben, bei RTL-Funktionen geht das eben nicht, die sind namentlich fix und vorgegeben.

Aber Deine Aussage "Einen procedure/function Alias gibt es nicht." wäre dann ja schon eine mir weiter helfende Antwort auf meine Frage.

Wie gesagt, ich habe ja geschrieben, dass ich Zweifel habe, ob das überhaupt Sinn machen würde, aber es interessierte mich einfach.
Und da ich inzwischen weiß, obwohl ich schon lange mit Delphi programmiere, dass es immer noch was zu entdecken gibt, was ich noch nicht kenne, kann man so eine Frage ja mal stellen.

Aber evtl. hätte ich mir noch ein wenig mehr Mühe mit der Frage machen und sie noch präziser formulieren sollen...

[KodeZwerg]

Zitat:

So könnte man Abkürzungen definieren etwa wie EFN (für ExtractFilename )

Dir steht frei eine Helfer-Unit anzulegen die sich vom Original Ableitet.

Delphi-Quellcode:

function EFN(const FileName: string): string;
begin
 Result := ExtractFileName(FileName);
end;

[Schokohase]

Zitat:

Zitat von Harry Stahl (Beitrag 1414910)

Der Unterschied zwischen RTL-Funktionen und meinen ist ganz einfach: Meine eigenen Funktionen kann ich umbenennen und im Zweifel einen kurzen aber prägnanten Namen geben, bei RTL-Funktionen geht das eben nicht, die sind namentlich fix und vorgegeben.

Das ist ein organisatorischer und kein technischer Grund.

[Amateurprofi]

@Harry Stahl:

Mir fällt nur eine Lösung ein, nicht ganz was du willst aber ...

Erstelle eine Unit, die du in allen Units unter Uses aufführst und schreibe in diese Unit Prozeduren/Funktionen mit den Namen, die Dir gefallen.

Und diese Funktionen rufen dann die Routinen mit den Dir zu langen Namen auf.

Ich hab mal etwas ähnliches gemacht, allerdings mit einer anderen Zielsetzung.

Bei mir war das die Prozedur ShowMessage.
Ich nutze die oft (so wie vermutlich jeder), um irgendwelche Rechenergebnisse, auszugeben.
Irgendwann war ich es leid immer zu schreiben

Delphi-Quellcode:

ShowMessage(IntToStr(A)+', '+IntToStr(B)+', '+IntToStr(C));

oder

Delphi-Quellcode:

ShowMessage(IntToStr(A)#13+IntToStr(B)+#13+IntToStr(C));

Also schuf ich solch eine Unit die u.A. zwei Prozeduren enthielt konnte dann schreiben

Delphi-Quellcode:

Mess([A,B,C]);

oder

Delphi-Quellcode:

Mess([A,B,C], #13);

oder auch

Delphi-Quellcode:

Mess(IntToStr(A)+' '+IntToStr(B)+' '+IntToStr(C));

Delphi-Quellcode:

interface

uses
   Vcl.Dialogs;

PROCEDURE Mess(const Args:array of const; const Delimiter:String=', '); overload;
PROCEDURE Mess(const S:String); overload;

implementation

PROCEDURE Mess(const Args:array of const; const Delimiter:String=', ');
var I:Integer; S:String;
begin
   for I:=0 to High(Args) do
      with Args[I] do begin
         case VType of
            vtInteger   :  S:=S+IntToStr(VInteger);
            vtBoolean   :  S:=S+BoolToStr(VBoolean);
            vtChar      :  S:=S+VChar;
            vtExtended  :  S:=S+FloatToStr(VExtended^);
            vtString    :  S:=S+VString^;
            vtPointer   :  S:=S+IntToHex(NativeInt(VPointer),SizeOf(Pointer)*2);
            vtPChar     :  S:=S+VPChar;
            vtObject    :  S:=S+VObject.ClassName;
            vtClass     :  S:=S+VClass.ClassName;
            vtWideChar  :  S:=S+VWideChar;
            vtPWideChar :  S:=S+VPWideChar;
            vtAnsiString:  S:=S+string(VAnsiString);
            vtCurrency  :  S:=S+CurrToStr(VCurrency^);
            vtVariant   :  S:=S+string(VVariant^);
            vtInterface :  S:=S+String(VInterface);
            vtInt64     :  S:=S+IntToStr(VInt64^);
            else           Continue;
         end;
         S:=S+delimiter;
      end;
   if S<>'' then SetLength(S,Length(S)-Length(Delimiter));
   ShowMessage(S);
end;

PROCEDURE Mess(const S:String);
begin
   ShowMessage(S);
end;

end.

[Harry Stahl]

@KodeZwerg und @AmateurProfi: Danke für Eure Antworten. Aber ich würde hier keine Lösungen haben wollen, die

A. Das Programm verlangsamen (Funktion ruft zusätzliche Funktion auf).
B. Das Programm größer machen.

Auch wenn beides im Einzelfall vielleicht nicht sonderlich ins Gewicht fallen würde.

Wenn es so etwas gegeben hätte, wie

Delphi-Quellcode:

Makro
  EFN = ExtractFilename;

Dann wäre das evtl. von Interesse gewesen, aber so etwas gibt's wohl nicht in Pascal/Delphi. Der Compiler hätte dann alle Stellen, wo EFN steht, durch ExtractFileName ersetzt. Dann gäbe es die oben beschriebenen Nachteile nicht.

[p80286]

Dein Vorhaben riecht doch sehr nach Präprozessor, gut, zu einer IDE-Integration kann ich nichts sagen, aber hier gibt es bestimm den einen oder anderen, der weiß wie man so etwas realisieren kann.

Gruß
K-H

[Harry Stahl]

Nachtrag: Hatte irgendwie dunkel in Erinnerung, dass unter C sowas ähnliches möglich ist (ich programmiere allerdings nicht in C, kann es gerade halbwegs lesen).

Hier mal ein Beispiel aus der BCC-Hilfe:

Code:

#define ERRMSG(x, str) printf("Fehler: %d \n%s", x, str) 

/*Im Code kann man dann den Aufruf machen, wie */
/*wird erweitert zu:  printf("Fehler: %d \n%s", 2, "Drücken Sie Eingabe, dann ESC"); */ 

ERRMSG(2, "Drücken Sie Eingabe, dann ESC");

Im übertragenen Sinne müsste da dann also sowas wie

Code:

#define EFN (x, str) ExtractFileName (x, str)

möglich sein.

[Harry Stahl]

C++ scheint da schon mehr drauf zu haben, da gibt es ne Menge Präprozessor-Direktiven, u.a. habe ich auch gefunden:

#pragma alias "aliasName" = "substituteName"

(teilt dem Linker mit, dass zwei Bezeichnernamen äquivalent sind)

[KodeZwerg]

Dann gäbe es da noch

Delphi-Quellcode:

const
  EFN: function(const FileName: string): string = SysUtils.ExtractFileName;

Volltreffer? ;-D

[himitsu]

Nunja, neben den Interface-Implementationen gibt es nocheine Stelle, wo man sowas auch mit normalen Funktionen machen kann, und zwar beim Import von DLL-Funktionen. :stupid:

Delphi-Quellcode:

unit himi.ist.manchmal.ein.bissl.irre;

interface

uses System.SysUtils;

function ITPD(const S: string): string;
  external 'NameDeinerAnwendung.exe' name 'IncludeTrailingPathDelimiter';  // nicht vergessen diese Zeile anzupassen

implementation

exports IncludeTrailingPathDelimiter(const S: string);

end.

[Harry Stahl]

Suuuperr!!!

KodeZwerg, Du bist ein Genie!:thumb:

Hier muss ich noch ein "System" davor setzen, so dass es compiliert:

Delphi-Quellcode:

const
  EFN: function(const FileName: string): string = System.SysUtils.ExtractFileName;

Keine Geschwindigkeitsverluste da und auch der Code wird nicht größer, am Ende der gleiche Ablauf auch in CPU-Ansicht (siehe Anlage), der Verlauf ist absolut gleich, "call ExtractFilename" ist mit der SpeicherAdresse von "call dword ptr [$005e199c]" identisch. Auch die Codevervollständigung funktioniert mit der "Alias-" Definition.

Gibt es noch eine allgemeine Bezeichnung für diese Art der Definition?

Jedenfalls dank an alle, die konstruktiv bei der Lösung mitgewirkt haben, es zeigt sich mal wieder, dass man sich nicht entmutigen lassen darf und einfach weiter der Sache nachgehen sollte, ganz egal was andere einem unterstellen wollen...:wink:

[KodeZwerg]

Ich nenne es Alias per Definition, aber fühl Dich frei das selbst zu Entscheiden hehe

[himitsu]

Zitat:

Zitat von Harry Stahl (Beitrag 1414939)

C++ scheint da schon mehr drauf zu haben, da gibt es ne Menge Präprozessor-Direktiven, u.a. habe ich auch gefunden:

In C++ hast du auch noch Makros, wo du seit Jahrzehnten alles kannst machen, wovon die Generics nur träumen können.

Code:

#define ITPD(s) IncludeTrailingPathDelimiter(s)

Zitat:

Delphi-Quellcode:

const
   EFN: function(const FileName: string): string = System.SysUtils.ExtractFileName;

Normaler Weise sind typisierte Konstanten eigentlich schreibgeschützte Variablen ... also ich hätte da jetzt nicht erwartet, dass es hier nicht so ist.

[Schokohase]

@KodeZwerg

Ein Alias ist das definitiv nicht, es fühlt sich aber so an und riecht auch so.

Darum: Respekt für diese kreative Lösung.


Es ist deswegen kein Alias, weil man bei einer Definitionsänderung (mehr oder weniger Argumente, andere Argumenttypen) diese Schein-Aliase nachführen muss. Bei einem echten Alias ist das nicht notwendig.

Das ist aber im Hinblick auf die RTL eher vernachlässigbar und darum hier nur ganz klein und unscheinbar angemerkt.

[bernau]

Zitat:

Zitat von Harry Stahl (Beitrag 1414907)

@Schokohase: Hast Du die Frage genau gelesen?

Und nein, ich bin mir nicht zu schade, um im Zweifel auch mal eine Frage zu stellen, wo jemand meinen könnte, den Kopf schütteln zu müssen.

Eine alte chinesische Weisheit sagt da:

Wer fragt, ist vielleicht ein Narr für fünf Minuten. Wer nicht fragt, bleibt ein Narr für immer.

:thumb:

Deine Eingangsfrage war eigentlich verständlich formuliert. Verstehe nicht, warum manche Fragen in Frage gestellt werden. Ist auch klar, dass du etwas anderes willst, als eine Procedure in eine andere Procedure zu stecken.

[KodeZwerg]

Zitat:

Zitat von Schokohase (Beitrag 1414968)

@KodeZwerg

Ein Alias ist das definitiv nicht, es fühlt sich aber so an und riecht auch so.

Darum: Respekt für diese kreative Lösung.

Nja ich sehs so:
Was macht man unter "const", man definiert etwas. In diesem Falle ein Alias. Also finde ich "Alias per Definition" schon passend.
Danke fürs Lob und Namensgebung hin oder her, erst der Denkanstubser wo TE anfing C++ Code zu zeigen anfing brachte bei mir den :idea: Effekt.
All you need is Team :wink:

[KodeZwerg]

Zitat:

Zitat von Harry Stahl (Beitrag 1414945)

Hier muss ich noch ein "System" davor setzen, so dass es compiliert:

Delphi-Quellcode:

const
  EFN: function(const FileName: string): string = {$IF CompilerVersion >= 23.0}System.{$ENDIF}SysUtils.ExtractFileName;

Sollte für beide Welten legitim sein :-D

[Stevie]

Zitat:

Zitat von Harry Stahl (Beitrag 1414903)

@ Stevie: Nö, weder XY-Problem, noch Single Level ob abstraction.

Während sich das XY-Problem ja auf den Fragesteller bezieht, wie nennt man es eigentlich, wenn der Antwortende nicht auf die eigentliche Frage eingeht (technische Machbarkeit), sondern statt dessen Vermutungen über Intentionen des Fragestellers oder gegebene Umstände ("sowieso unübersichtlicher Code") anstellt?:wink:

Ich sags mal so: was du in deinem eigenen Code, den nur du lesen und warten musst, machst, ist mir herzlich egal - ich sprach das nur an, weil man ja auch manchmal Code schreiben möchte, der auch für andere verständlich ist, und wenn man da plötzlich nur noch TLAs im Code findet, wo man erstmal grübeln muss, was sie bedeuten, dann fördert das nicht die Lesbarkeit. Also entschuldige bitte, wenn ich auch mal über die eigentliche Fragestellung hinausblicke :)