Delphi Unit (Language Binding) für eigene C-Lib - Umsetzung

[mensch72]

zu 1:
- fände es gut, wenn die LowLevel Umsetzung sich möglichst nah am 1:1 Prinzip orientiert, denn:
- die CLIB Sachen setzt entweder der ein, der sie von C "so" kennt
- oder jemand ohne viel C-Erfahrung portiert einen C-Source wo ja auch die Urform verwendet wird
- wer in Delphi eine "optische" Kapselung will, kann ja den NameSpace stets mit davor schreiben... ala clib.atoi('123')
- eine Delphi OPP Schicht zur unterstützung von SprachFeatures kann für Step 2 und Leute mit Delphi&C Erfahrung nicht schaden, ist aber dann nicht mehr rückwärtsprotabel, ausser es man erstellt gleiches auch als logisch kompatibel gleich mit in CPP


zu 2:
- für pure 1:1 Portierung wäre es im Prinzip egal, weil wer C Quellen 1:1 umsetzt, sieht dort ja die "Header includes", kaönnte die also 1:1 als "Delphi uses" übernehmen, ABER in C ist die Reihenfolge fast wurcsht und man hat dort oft mehr include als nötig, denn es wird zur Vermeidung von "mehrfachen Defines/Typen/..." einfach in den Headern stets gefragt, ob das Defines des HeaderFiles noch nicht definiert is, dann wird es "einmal" definiert und alles nötige gamacht. Bei den nächsten 100 includes passiert dann nix mehr.. das ist in C & CPP ja so üblich, da streikt aber das Konzept der DelphiUses im InterfaceTeil und kann nur per Trick und viel Mühe im Einzelfall durch "ImplemenationUses" von Kreuzreferenzen befreit werden...

-> also besser alles LowLevel in EINE CLib unit (auch wenn das den DelphiLinker dazu verleitet die EXE mit vielen wohl ungenutzten Sachen etwas aufzublähen.
-> ein CLIB.INC Files, welches im InterfaceTeil bei uses einfach per include eingebunden wird, hält die Option offen, es später doch in mehrere .pas Units aufzuteilen, da aber nur C Kenner wissen, was sich in welcher UNIT/Header, wäre dies Option mehr der Ansatz für C Spezialisten, sich hier ihre eigenen Sachen "zentral" mit einzu binden


CLIB4PAS klingt definitiv interessant!
Hatte vor Jahren mal für 100T Pas-VCL-CodeZeilen sowas rückwärts gemacht, also quasi ne echte CPP VCL gemäß der CPP Header vom C++Builder relalisiert, damit man auch in VC z.B. eine VCL Stringlist, TList,... oder einen VCL (C)AnsiString hatte... das hat mir damals bei der schnellen ersten Version einer PAS->CPP Portierung eines guten PAS BackEnd Frameworks sehr geholfen.
Den so generalisierten Ansatz wie du jetzt hier planst habe ich selbst nie gemacht, beim manuellen C->PAS Convert nutze ich nur eine eigene PAS unit, wo ich eben all die Dinge über die zeit so rein genommen haben, welche ich in meinen C Quellen eben so verwende