C Compiler und Cross-Plattform-UI

[GPI]

TinyC ist schon mal sehr interessant, iup auch.

Vielleicht mal zur Erklärung, warum ich frage und warum C und nicht C++.

Ich spiele immer noch mit den völlig unsinnigen Gedanken, mir meine eigene Basic-Programmiersprache zu gestallten. Und als Basis dann C und nicht Assembler. Aus mehreren Gründen. A) Ich kann kein Assembler. B) Um dann auch noch optimierten Code zu schreiben, reicht mein wissen erst recht nicht. C) C ist deutlich leichter zu lernen D) Ist nahezu überall verfügbar.
Wenn man sauber definiert und erstmal nur die C-ANSI-Standard-Bibliotheken nutzt, hat man ein schönes Grundgerüst, das sogar auf einen ATARI-ST laufen würde, wenn man einen C-Compiler findet.
Was PureBasic imo ausmacht, sind die mitgelieferten Bibliotheken. Das alles zu erarbeiten wird ein Eck lang dauern. Eine Warper-DLL darf man ja nicht verwenden und es ist ja nicht schwer zu verstehen warum.
Noch einen Vorteil würde es geben: Man kann theoretisch relativ leicht C-Bibliothek einbinden bzw. generell C-Code.
Ein paar Sachen hab ich mir schon überlegt, was ich gerne umsetzen würde. Declare möchte ich bspw. komplett abschaffen. Mag für höhere Programmiersprachen dazu gehören, ich finde in einen Basic hat das nicht sooo viel zu tun. Einen Variablen-Typ "Auto" möchte ich hinzufügen. Der Typ wird dann bei der Benutzung festgelegt. Bspw. ein a="hallo" würde a automatisch zum String machen. Ein anschließendes A=1 würde dann ein Fehler verursachen. Wer den Typ lieber manuell festlegen will, kann das mit a\s machen - \ wird ein Typ und Konvertierungszeichen. Damit wird dann der . für Strukturzugriffe frei - und damit benutzt wie bei jeder anderen Programmiersprache. Und bei Pointern möchte ich eine Typensicherheit einführen. ein " b="hallo" : a\*i = @b " würde ein Fehler verursachen weil @b ein String-Pointer zurückgibt, *a aber als Pointer auf Integer angelegt wurde. ein " B="Hallo":a\*i=(@b)\*I " würde wieder gehen, weil der Pointer "Konvertiert" wird.
Ob das ganze überhaupt was wird? Keine Ahnung, ich plane erstmal und sammle. Gerade das mit den Pointer ist noch so ein Ding. *\ gefällt mir noch nicht so ganz.
Ich hab mir jetzt erstmal "C von a bis z" gekauft und werd da erstmal rumexperimentieren. Notfalls erschlag ich damit ein paar Fliegen - der Wälzer wäre dick genug
Einen bescheuerten Namen hätte ich sogar "Basil - a BASIc Language"

[ccode_new]

Ich spiele immer noch mit den völlig unsinnigen Gedanken, mir meine eigene Basic-Programmiersprache zu gestallten. Und als Basis dann C und nicht Assembler.

Bist du Wahnsinnig ?




Wie hast du dir die Erstellung den im Detail vorgestellt ?

Bitte eine kleine Erklärung. Mit Makros ?

Soll das ein Wrapper, Interpreter oder ein Compiler werden ?

Ich habe ja mal vor langer Zeit ein bisschen im "Drachenbuch" gelesen und mit ANTLR (JAVA) und JASMIN-Java-Assembler herrumgespielt, habe es dann aber sein gelassen.
Viel ist nicht daraus geworden.

Was ist denn genau dein Konzept / Ziel ?

[Kiffi]

@GPI: Hier kannst Du Dich ja inspirieren lassen:

BCX: https://en.wikipedia.org/wiki/BCX
BaCon: http://www.basic-converter.org/

Grüße ... Peter

[GPI]

Soll das ein Wrapper, Interpreter oder ein Compiler werden ?
...
Was ist denn genau dein Konzept / Ziel ?

Naja, so kompliziert ist es eigentlich nicht. er nimmt den "Basil"-Code und übersetzt in in C, anschließend jage ich das ganze den C-Compiler. Fertig.

Das ist ja das schöne, wenn man C und nicht Assembler benutzt - viele Structuren sind ja da schon da, die man nutzen kann.
aus einen fiktiven code wie

Code: Alles auswählen

a=20.0
a=math.sqr(a)

müsste er sowas machen

Code: Alles auswählen

//alle includes die irgendwo benötigt werden sammeln und hier eintragen
include <math.h>
// "Declares" zu funktionen
// Globale Variablen
int main(int argc, char **argv) 
{
//a=20.0
double dBL1=20.0
//a=math.sqr(a)
dBL1=sqrt(dBL1)
}

Die Variablennamen müssen wohl umbenannt werden. Wie genau, ob einfach nummeriert oder nur mit einen BL_ - Prefix, weis ich noch nicht. Soll halt Namenskonflikte mit weis was ich alles vermeiden. Basic ist ja normalerweise nicht Case-Sensitiv, C schon.

ich plane das man sogar sowas schreiben kann:

Code: Alles auswählen

$Include <math.h>
a=1 ; a ist damit Integer
a=( $sqrt( a\d ) )\i

Das $ ist das "C-Befehl" - damit kann man C-Code direkt eingeben. Allerdings geht es nur bis zur nächsten Nicht-Bezeichner-Zeichen. In der Klammer von sqrt() ist quasi wieder Basil-Code. hier übergebe ich die Variable a (integer), konvertiere sie aber vorher zu double. Den Wert, den ich durch das c-sqrt() zurück bekomme, wird dann wieder in Integer umgewandelt ( durch \i )
Das $-CTeil ist aber kritisch. Da Basil nicht weis, was der C-Befehl für parameter und was der genau zurück gibt, muss man genau wissen, was man da macht.
Fehlermeldungen, die hier entstehen können, werden durch Basil nicht abgefangen werden, sondern man bekommt die Fehlermeldung des C-Compilers serviert.
Das ganze ist für mich auch eher dafür gedacht, um Bibliotheken für Basil aufzubauen. Da kann man genauer abfangen. Man soll so auch bspw. die Windows-Api direkt aufrufen. Aber ich würde es nicht empfehlen. Was auch gehen wird, direkt Konstanten abzufragen. bspw. $TRUE wäre die C-Konstante True.

Was auch auf meiner Todo-Liste steht: Libraries erstellen. Fand ich schon immer blöd, das man das in PB nicht direkt machen kann.
Genauso soll beim "Create Execute" auch eine <programmname>.license.txt erstellt werden und wenn DLLs benötigt werden automatisch ins Verzeichnis kopiert werden. Die licence.txt enthält dann alle Licence-Informationen der tatsächlich benötigen eingebundenen Bibliotheken.

Aber nicht so viel Nachdenken, sonst erschlägt man sich damit und traut nicht mal anzufangen.

Imo kommt der "Dumme" öfters weiter, weil er halt einfach macht und es schafft, während der "Kluge" sich zu tode überlegt.
Die erste Version von Basil wird in PB geschrieben - und ich werd mich hier melden. Falls das jemals was wird und vor Weihnachten (ich sag nicht welches Jahr) wird das auch sicher nichts. Aber aktuell hab ich spaß dran hier probleme zu lösen.

@kiffi danke. ich werds mir später anschauen.

[edel]

Im übrigen ist Pelles C Freeware. Da hast du dann alle Werkzeuge zusammen und darfst es auch verteilen.

[Sicro]

Hallo GPI,

das ist eine coole Idee

Dein Vorhaben nennt sich übrigens Source-to-Source Compiler, Transcompiler oder Transpiler:
https://de.wikipedia.org/wiki/Compiler#Sonderformen
https://en.wikipedia.org/wiki/Source-to-source_compiler

Genauso soll beim "Create Execute" auch eine <programmname>.license.txt erstellt werden [...] Die licence.txt enthält dann alle Licence-Informationen der tatsächlich benötigen eingebundenen Bibliotheken.

Dafür habe ich seit kurzem ein PB-Tool geschrieben. Die Liste im Thread "Welche PB-Befehle verwenden welche Libraries?" war die Vorarbeit dafür. Kläre derzeit nur noch mit Fred ab, ob die Liste so korrekt ist.

Edit:
Wahrscheinlich kennst du die Seite schon, aber sicherheitshalber möchte ich sie hier trotzdem nennen:
http://rosettacode.org/wiki/Rosetta_Code
Sie wird dir bestimmt sehr bei deinem Vorhaben helfen.

[DarkSoul]

Die verfügbaren GUI Bibliotheken sind nur soweit cross-plattform, wie sie angeboten bzw. kompatibel sind.

GTK ist ein ziemlicher Mist und zudem ein Flickenteppich. Da werden APIs gerne mittendrin geändert und du hast das Nachsehen, wenn ein "kleines" Update kommt.

Viele GUI-Libs, die auf Cross-Plattform zielen, sehen auf einigen Systemen "falsch" aus. Es sind dann nicht die gewohnten Standard-Steuerelemente des jeweiligen Systems, sondern eine Zwischenschicht. Das ist z.B. bei Swing so (zumindest noch vor einigen Jahren. Inzwischen ist es besser geworden).

Da kannste gleich zu WebView+HTML5 greifen.

Warum machst du es nicht so, dass du für jedes unterstützte Betriebssystem eine Zwischen-Lib baust, die die Kompatiblität zwischen deiner Programmiersprache und der jeweils verfügbaren UI-Lib bzw.der System-API herstellt? Dann bindet der Compiler/Linker je nach Zielsystem entweder die eine oder die andere ein und du kannst die Unterstützung beliebig erweitern.

PS: Java ist nicht zwingend langsamer als C. Kann sogar in einigen Fällen schneller sein, weil der Bytecode gezielt auf das Zielsystem, auf dem er ausgeführt wird, abgestimmt werden kann, als vorcompilierter Code aus einem "normalen" Compiler.

[juergenkulow]

Hallo GPI,

wenn Du es jeden Tag versuchst, versuchst, versuchst bin ich gespannt was Du am 22.12.2022 veröffentlichst.

Man kann auch PureBasic nutzen um C zu erzeugen:

Code: Alles auswählen

; Erzeuge C-Demo. 

EnableExplicit
Macro NeueZeile : #CRLF$ : EndMacro ; Windows 
Macro quot : Chr(34) : EndMacro     ; Anführungszeichen 
Macro stradd(Text) : s$+Text : EndMacro ; Hier könnte auch ein AddElement(Liste()) stehen. 
Macro strprint(Datei) : mystrprint(Datei,s$) : EndMacro
Declare mystrprint(Dateiname.s,s$) 
Define s$="" ; Kommt bei Umstellung auf Liste weg. 

stradd("#include <stdio.h>"+NeueZeile)
stradd("int main (void) {"+NeueZeile)
stradd("  printf(") 
stradd(quot+"Hallo sichtbares Universum. jp こんにちは可視宇宙 hi हेलो दृश्यमान ब्रह्मांड \n"+quot+");"+NeueZeile)
stradd("  return 4711;"+NeueZeile)
stradd("}"+NeueZeile)

strprint("hallo.c") 

Procedure mystrprint(Dateiname.s,s$) 
  Protected Datei
  Datei=CreateFile(#PB_Any,Dateiname)
  If 0=Datei :  Datei=CreateFile(#PB_Any,GetUserDirectory(#PB_Directory_Documents)+Dateiname) :endif
  WriteString(Datei,s$)
  CloseFile(Datei)
EndProcedure

Was gibt das erzeugte C Programm wirklich aus?

Pelles C
Drachenbuch
N.Wirth Compiler Construction Part 1
N.Wirth Compiler Construction Part 2

Gruß

Edit: If 0=Datei : Datei=CreateFile(#PB_Any,GetUserDirectory(#PB_Directory_Documents)+Dateiname) :endif

[Beefi]

Hi GPI,

ich muss zugeben, ich habe jetzt nicht den ganzen Thread gelesen und beziehe mich gerade nur auf deine GUI-Frage im ersten Post.

Unter C kann ich dir drei GUI-Umgebungen empfehlen/nennen:

IUP - Portable User Interface:
Hiermit kannst du sehr einfach und im Stil ähnlich wie in PureBasic GUI-Anwendungen erzeugen.
Es gibt auch schöne Tutorials auf der Seite.
IUP läuft auf sämtlichen UNIX-Systemen und auch auf Windows.
Leider nicht auf MacOSX...es gibt dafür aber ein Backend (nicht getestet).


Nuklear:
Diese GUI-Bibliothek ist tatsächlich nur EIN EINZIGER Header. Also du musst nur die Header-Datei in deinen Projekten einbinden und los gehts.
Das hört sich toll und easy an...ist es auch was das Kompilieren betrifft...aber bei der Verwendung bin ich noch nicht so ganz durchgestiegen.
Oder sagen wir es mal so...der Code ist hier richtig typischer C-Style, der etwas unverständlich und kompliziert ist
Nuklear läuft auf so ziemlich allen relevanten Betriebssystem, auch auf Android


Dann gibt es noch GTK...das wurde dir bestimmt auch in diesem Thread vorgeschlagen.
GTK hat mich jedoch nie so interessiert, da es eigentlich für Linux ist...es gibt GTK auch für Windows, aber damit wird man nicht richtig glücklich und hat eher Probleme,
alleine schon um es zum Laufen zu bringen (das ist bei mir aber schon ein paar Jahre her...vielleicht wurde es besser).

Noch eine kleine Empfehlung aus meiner Erfahrung:
C ist zwar eine Plattformunabhängige Sprache, aber man merkt mit der Zeit immer mehr, dass dies eigentlich bedeutet, dass man mit dieser Sprache auf mehreren Systemen Anwendungen schreiben und kompilieren kann. Es heißt jedoch aber nicht, dass man damit so einfach eine Anwendung schreiben kann und diese auf knopfdruck für verschiedene Systeme kompilieren kann.
Man rutscht mit den meisten Anwendungen auf Plattformspezifische Bereiche ab, so dass man schnell den Salat hat und separate Codeabschnitte mit Systemprüfungen für die jeweiligen Betriebssysteme schreiben muss.
Falls du für Mac kompilieren möchtest, benötigst du eigentlich auch zwingend einen Mac mit OSX, weil es auch nur dort die benötigten System-Bibliotheken (API) gibt...aber den hast du ja vielleicht.
Bei MacOSX musst du auch immer ein wenig mit am Ball bleiben, da es nicht immer Programmiererfreundlich ist und gewisse Dinge einfach mal nicht mehr funktionieren
Als Beispiel: OpenGL und OpenCL ist auf Mac Geschichte...die haben jetzt ihr eigenes Zeug gemacht: Mojave.
Für Linux kannst du quasi auch einfach VirtualBox nehmen.
Falls du Programme schreiben möchtest, die ganz easy (ohne großartiger Änderung) auf allen drei Systemen laufen, empfehle ich, auf eine Interpreter-Sprache zu setzen, die von einer Laufzeitumgebung abhängig ist, und nicht vom Betriebssystem...Beispiel Python, Java, B4J (basiert auf Java), C# (mit Mono/Xamarin/.NET). DIese Laufzeitumgebungen sorgen dafür, dass du dich um nichts auf den verschiedenen Systemen kümmern musst...du programmierst nämlich für die Laufzeitumgebung und nicht über die direkten API-Schnittstellen des Systems.
Falls du gerne eine Compiler-Sprache nutzen würdest und möglichst ohne Aufwand auf verschiedenen Systemen kompilieren möchtest, solltest du auf ein Framework setzen, dass einen möglichst von der Betriebsystemebene entfernt (z.B. QT, Ultimate++)...oder als Gesamtpaket PureBasic
Aber auch mit Purebasic (und anderen Frameworks) muss man hin und wieder auf gewisse Funktionen verzichten, oder diese anders Lösen (durch Systemspezifischen Code), sonst ist man schnell wieder nur bei der Kompatibilität zu einem Betriebssystem.
Für C fällt mir hier auch leider kein Framework ein...die GUI-Libs werden auf allen Systemen gleich programmiert, aber der Rest ist meist stark Systemabhängig.

Ich hoffe, ich konnte mit den GUI-Empfehlungen ein wenig weiterhelfen. Der vorherige Absatz ist nur meine persönliche Meinung, die mir gerade noch dazu eingefallen ist...diese Themen werden aber sehr unterschiedlich gesehen. Da muss man einfach selbst ein wenig reinschnuppern, welche Sprache einem am meisten gefällt.
Aktuell arbeite ich mich ein wenig in FreePascal (ObjectPascal/Delphi) mit Lazarus ein (auf Empfehlung eines Forum-Nutzer "ccode_new")...es ist eine richtige Compiler-Sprache, hat eigene GUI an Board und abstrahiert stark von der Betriebssystemebene...laut Buch kann es meist ohne Änderungen auf Linux, Windows und Mac kompiliert werden...aber so weit bin ich noch nicht

Viele Grüße,
Andi