BlueBasic Compiler

Übersicht Kommentare Worklogs

Gehe zu Seite Zurück  1, 2


flona

 Link zu diesem BeitragSo, Apr 25, 2010 18:42
Wegen den "optionalen Parametern" (Default-Parameter): Warum steigst du nicht einfach auf C++ um?
www.Dreier-Florian.kilu.de
Intel Core 2 Quad Q9400 | Zotac 9800GT | 4GB RAM | 1TB HDD | Windows 7 Professional 32bit

Thunder

 Link zu diesem BeitragSo, Apr 25, 2010 19:26
Weil ich C++ nur "flüchtig" kann(also über bestimmte C++-typische Konstrukte wenig bis nichts weiß) und nach C kompilieren sowieso schon ineffizient genug ist.
Ich habe zwar ein C/C++ Kompendium, aber den C++ Teil nur überflogen, da mich die OOP nicht sonderlich interessiert.
Allerdings finde ich, dass der Umstieg auf C gut ist, da alles plattformunabhängig ist und gcc auf jeder Linux-Distribution die ich kenne vorinstalliert ist - man müsste also nicht g++ runterladen.
Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

Noobody

 Link zu diesem BeitragSa, Jun 05, 2010 16:11
Zitat:
Außerdem habe ich eine Theorie aufgestellt und zwar darüber, wieso BB Variablen, die zum ersten Mal benutzt werden,
deklariert.

BB ist insgesamt eher an Anfänger gerichtet, daher wollte Mark vermutlich auf eine am Anfang verwirrende zwingende Deklaration verzichten. "Man braucht eine Variable? Einfach benutzen und gut ist!" war vermutlich seine Idee Razz

Zitat:
ich habe keine Ahnung was blitzcc macht - ich bleibe bei meiner Theorie, die besagt, dass BlitzBasic NICHT kompiliert wird

Natürlich wird BB kompiliert! Einfach direkt nach ASM und nicht über C.

Zitat:
Zumindest, wenn man nach C kompiliert ist es viel einfacher wenn man einfach alles deklariert,
was einem in den Weg kommt.

Eigentlich ist eher das Gegenteil der Fall. Wenn man strikt deklarieren muss, dann muss der Compiler nur nach Local oder Global mit neuen Variablen rechnen. Trifft er irgendwo auf einen Bezeichner, den er nicht kennt, ist nur ein Fehler auszugeben und abzubrechen. Bei der Autodeklaration hingegen muss er bei jedem Bezeichner, der angetroffen wird, prüfen, ob dieser schon existiert, und ihn zu den existierenden Variablen hinzufügen, wenn er das nicht tut. Das ist einer der Gründe, warum BB mühsam zu parsen ist - ständig muss man mit neuen Variablen rechnen.

Abgesehen davon darf man nicht davon ausgehen, dass die Syntax einer Sprache nach dem Kriterium "möglichst einfach zu kompilieren" entwickelt wird. Man hat hier nicht mit einem Hobby-Entwickler zu tun, der komplizierte Features nicht in seine Sprache implementiert, weil er zu faul ist, komplizierteren Code zu parsen, sondern mit jemandem, der über ein Jahr oder länger die Sprache entwickelt, um am Ende damit seinen Lebensunterhalt zu verdienen Wink
Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun

Thunder

 Link zu diesem BeitragSa, Jun 05, 2010 21:38
ich muss anscheinend einsehen, dass BB kompiliert wird.
Allerdings; wenn man den Compiler so aufbaut, wie ich das getan habe, bin ich mir ziemlich sicher, dass es einfach gewesen wäre, alles zu deklarieren. Überprüfen, ob es die Variable schon gibt, muss ich so und so, damit der Benutzer nicht vor irgendeiner Fehlermeldung des gcc sitzt, die er möglicherweise gar nicht versteht.
Ich hab es mir auch nie einfach vorgestellt BASIC zu kompilieren; ich habe schon davor oft gehört, dass das ein weitverbreiteter Irrtum ist.
Bevor ichs vergesse: komplizierten Code parsen IST mit komplizierten Komplikationen verbunden.
Aber wie gesagt, gebe ich mein Bestes.

Trotzdem danke, wegen der Klarstellung in Sachen BB und Kompilation.
Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

Noobody

 Link zu diesem BeitragMo, Jun 07, 2010 16:33
Zitat:
Dieser würde nämlich schon vom Präprozessor entfernt und der
Compiler bekäme ihn gar nicht zu Gesicht.

Ein Kontextunabhängiger Präprozessor ist aber gefährlich Razz Was würde z.B. passieren, wenn ich ' in einem String verwende?

Wegen solchen Problemen sollte der Präprozessor eigentlich nicht auf dem Quelltext als String arbeiten, sondern während der Konvertierung zu Tokens seine Arbeit tun. Dabei liest er den Quelltext Zeichen für Zeichen ein und setzt diese zu Token zusammen. Trifft er während diesem Schritt auf ein Anführungszeichen, liest er alles überprüfungsfrei ein bis zum nächsten Anführungszeichen. Trifft er auf ein InlineC, liest er alles überprüfungsfrei ein bis zum nächsten EndInlineC. Treffen die vorherigen Bedingungen nicht ein und trifft er dann noch auf ein ;, dann überspringt er alles nachfolgende bis zum nächsten Zeilenvorschub. So kannst du das Kommentarzeichen problemlos beim ; belassen.

Und nur so als Tipp: ' ist ebenfalls ein Sprachbestandteil von C. Bei folgender Zeile würde dir der Compiler also um die Ohren fliegen [code]printf( "Hello %corld!", 'W' );[code]
Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun

Thunder

 Link zu diesem BeitragMo, Jun 07, 2010 16:43
brrr... das mit den Strings habe ich bedacht. Damit gibt es keine Probleme, aber für den Tipp ganz unten bin ich dir sehr dankbar. Das wäre mir wahrscheinlich erst einige Zeit später aufgefallen.
Mein Compiler ist allerdings anders aufgebaut und lässt es zwar eigentlich zu, Kommentarzeichen zur Laufzeit zu entfernen, aber ich habe mich dazu entschieden das in den Präprozessor zu packen.
Bei mir werden die Tokens zur Laufzeit eingelesen - kein Syntaxbaum oder Ähnliches.
Mal sehen, wie ich diese Probleme mit den Kommentarzeichen behebe.


mfg Thunder
Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

Silver_Knee

 Link zu diesem BeitragDo, Jun 10, 2010 22:45
na ganz einfach:

Code: [AUSKLAPPEN]
InlineC
printf("x=y+1 und y=x-1\n");

EndInlineC


ab dem Wort InlineC wird alles 1:1 in den C-Code übertragen bis zu der Zeichenfolge "EndInlineC"

Thunder

 Link zu diesem BeitragFr, Jun 11, 2010 13:27
@Silver_knee: Das ginge aber nicht, wenn die Kommentarzeichen (egal ob ; oder ') vor dem kompilieren entfernt würden. Dann würde es die gar nicht im Code geben und daher kam diese Umstellung auf Entfernung der Kommentarzeichen zur Kompilierzeit.
Der Präprozessor kann nämlich nicht wirklich unterscheiden, ob da jetzt das InlineC 1. an einer richtigen Stelle steht und nicht zu einem Syntaxerror führt, 2. ob es in einem String steht ...
Es ist viel komplizierter das alles zu berücksichtigen, als einfach die Entfernung dem Compiler selbst zu überlassen, wobei Compiler und Präprozessor eigentlich ein Programm sind (bei BlueBasic).

mfg Thunder
Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

DAK

 Link zu diesem BeitragMo, Apr 16, 2012 14:06
Muss sagen, das Projekt klingt sehr intressant. Zum Mitarbeiten fehlt mir im Moment wohl leider die Zeit, aber verwenden würde ich das Fertige schon gerne.
Gewinner der 6. und der 68. BlitzCodeCompo

DaysShadow

 Link zu diesem BeitragSo, Jul 29, 2012 10:59
Nur zur Info: Int und Long sind in BMax signed, nur Byte und Short sind unsigned.
Könnte ansonsten zu Problemen führen.
Blessed is the mind too small for doubt

Thunder

 Link zu diesem BeitragSo, Jul 29, 2012 11:56
Bezüglich Int habe ich ja nichts anderes behauptet, aber das mit Long ist natürlich ärgerlich. Irgendwie bin ich davon ausgegangen, es sei unsigned. Wird gleich sowohl im Quelltext als auch im Worklog ausgebessert.
Danke dir!
Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

DAK

 Link zu diesem BeitragMo, Jul 30, 2012 12:26
ich find das projekt sehr intressant. compilerbau hat mich immer schon interessiert. viel erfolg!
Gewinner der 6. und der 68. BlitzCodeCompo

Thunder

 Link zu diesem BeitragMo, Jul 30, 2012 20:01
Danke! Ich schreibe BlueBasic auch hauptsächlich, weil ich am Compilerbau Interesse habe. Der spätere Zweck wäre natürlich super, aber ich habe das Gefühl, dass ich noch eine ganze Weile vor einem unfertigen Programm sitzen werde ^^
Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

Gehe zu Seite Zurück  1, 2


Übersicht Kommentare Worklogs