TAN ohne math-include
-
Original erstellt von <TS>:
zu 2: das habe ich auch früher gedacht, befor ich die header angesehen habe *g*Ich denke du solltest nochmal ganz von vorne anfangen... Denn ganz am Anfang wurdest du auf das ungünstigste Gleis umgelenkt, nämlich auf das Gleis der Leute die vorhandene gute Sachen besser machen wollen anstatt sich neuen Problemen zu widmen und irgendwann begreifen, dass sie es doch nicht besser geschafft haben um dann frustriert das programmieren sein zu lassen...
-
Naja jetzt habe ich schon gefunden wie das geht - ich könnte schwören ich habe das min. 2x vorher genau so ausprobiert - aber es ging nicht... naja ist jetzt auch egal...
Neee also meine Idee war etwas neues zu erschaffen... Wenn ich jetzt die header von c++ belasse, dann wird das deutlich unsauberer... ob das überhaupt möglich ist und bei welchen aufwand, das weiß ich noch nicht - das ganze wird erstmal ein Prototyp. Wenn das was wird, dann wird die Bibliothek ausgebaut mit vielen Funktionen, die sich dynamisch zusammensetzen lassen...
Naja ich habe mir bisher noch keine großen C++-Codes gesehen. Aber so wie diese GCC-Header geschrieben sind, das ist glaube ich das Schlimmste was ich jemals im leben gesehen habe... Da ist die Hälfte irgend so ein Kompatibilitätsscheiss drin... Einfacher gesagt: Schlimmer als diese Header kann es nicht mehr werden, sondern nur besser... wenn ich mir dagegen meine neue Header ansehen (von denen ich bisher aber nicht viel habe) - dann sieht es gleich vernünftiger und strukturierter aus...
-
Vielleicht noch eine kleine Randbemerkung:
Grundsätzlich finde ich die Idee gar nicht so falsch, auf den GCC aufzusetzen und von Deiner Sprache erst mal auf C/C++ zu übersetzen. Damit hat man sich den richtig schwiedrigen Teil eines Compilers zum Teil gespart.
Aber nun nochmal zu Deinem "Include-Wahn": Das Du für eigene Funktionen auch Deine eigenen Include-Dateien schreibst ist ja richtig, aber warum willst Du zum Freck auf die "Standard"-Includes verzichten? Vielleicht denkst Du ja, dass Dein Programm kleiner wird, wenn Du nicht (c)math.h einbindest. Grosser Irrtum! Es kommt drauf an, gegen welche Bibliotheken der GCC in Dein Programm linkt. Die Header-Files der einzelnen Bibliotheken machen die Funktionen in Deinem Programm nur "sichtbar", aber der sin, bzw. cos-Code (oder tan-Code) ist ohnehin in Deinem Programm drin, wenn die entsprechende Bibliothek reingelinkt wird, egal ob Du math.h "includest" oder nicht.
-
es ist voellig egal, wie es in den headern aussieht. die haben fuer dich black boxes zu sein. im standard steht, was die machen.
und wenn da so viele kompatibilitaetssachen drin sind sei froh, dann brauchst du das nicht selbst schreiben.
-
Man könnte natürlich auch direkt die Assembler Befehle FSIN und FCOS verwenden, die dann mit asm("..."); eingebunden werden können.
-
Original erstellt von <keymaster>:
Man könnte natürlich auch direkt die Assembler Befehle FSIN und FCOS verwenden, die dann mit asm("..."); eingebunden werden können.Was meinst du was die C-Library-Funktionen machen? Ausserdem geht das nicht mit asm("...") sondern mit __asm ... oder __asm { ... ]
[ Dieser Beitrag wurde am 24.03.2003 um 15:38 Uhr von MaSTaH editiert. ]
-
hmm weil ich mich grad dafür interessiert hab hab mich mir die blackboxes doch mal angeschaut... die math.h ist interessant... zuerst scheint alles wie ich es erwartet hab. ein haufen declarationen... aber dann sind kurioserweise doch ein par funktionen direkt in den headern vorhanden (die genau diese asm statements verwenden).
man könnte natürlich noch auf die idee kommen sich eigene header zu bauen mit oprimierten befehlen sse 3dnow etc. aber das sollte die compiler ja eigentlich können
-
Das mit Include-Wahn wird wohl nicht anders gehen, denke ich - ich glaube das werde ich sowieso paar anderen Leuten überlassen und mich eher auf IDE und Konverter konzentrieren... (hehe)
Naja das math in exe immer eingebaut wird - das ist schon klar... allerdings habe ich bei einigen anderen inkludes gesehen, das schon ein einfaches einbinden ins programm die exe vergrößert, ohne dass ich überhaut eine funktion verwende. z.b. ist die exe dann statt 7 KB irgendwie 35KB groß geworden - naja und das soll halt verhindert werden...
und überhaupt soll das ganze ja etwas anders werden. Z.B. wird es kein cout<<text; geben. Stattdessen gibt es dann funktionen. besser gesagt - alles was an funktionen da ist, wird vom konverter nahezu 1:1 übersetzt. ich muss dann nicht beachten wie den nun ein befehl richtig in nativen c++ code umgewandelt wird und welche inkludes ich dazu benutzten muss - ich weiß dann sofort: inkludiere funktion x - fertig. hat dann zur folge, dass alle inkludes neugeschrieben werden müssen - jedoch gibt es auch vorteile. Z.B. wenn funktion X fehlt, dann einfach c++ code schreiben für funktion coden - und schon soll es als neue funktion erkannt werden und bei bedarf eingebaut werden... dadurch können alle inkludes von allen recht einfach geschrieben werden...
-
Original erstellt von <TS>:
Das mit Include-Wahn wird wohl nicht anders gehen...
...und überhaupt soll das ganze ja etwas anders werden. Z.B. wird es kein cout<<text; geben. Stattdessen gibt es dann funktionen. besser gesagt - alles was an funktionen da ist, wird vom konverter nahezu 1:1 übersetzt.Ich bin mir nicht sicher, ob Du auf dem richtigen Weg bist. Mir scheint es so zu sein, als würdest Du es für eine oberste Priorität empfinden, dass der "Zwischencode" (also C/C++) in eine menschlich lesbare Form übersetzt werden muss. Ausserdem möchtest Du hunderte von .c und .h-Dateien mitliefern?
Wenn ich Dein Prinzip richtig verstanden habe, dann soll eine Übersetzung von Deiner Sprache X in ein ausführbares Programm doch so funktionieren:
test.x -> (konverter/compiler) -> test.c/.h -> (gcc) -> test
Wenn Du Dich mit dem Konverter auseinander setzt, dann hast Du Dich sicherlich schon mal (f)lex, (b)yacc, bison, etc. auseinander gesetzt (wenn nicht, dann solltest Du das machen!!!!). Findest Du den Code noch lesbar, den die Programme erzeugen? Ich finde dies nicht, aber das ist auch egal. Man muss den Code nicht verstehen, den einzigen Code den man verstehen muss, sind dort die Spezifikationsdateien, und in Deinem Fall wäre dies die Datei test.x .
Wenn ich in Deiner Sprache etwas programmiere, dann werde ich mir die Dateien test.c/.h nicht mehr anschauen. Am liebsten wäre es mich ja sogar, wenn die IDE diese Dateien auch sofort wieder löscht, so dass ich sie erst nie zu Gesicht bekomme. Und deshalb kann es nun egal sein, ob test.c sehr übersichtlich ist, für jeden verwendeten Befehl einen include hat oder ob dies eine 10 MB grosse, nicht verständliche Datei ist. Für den zweiten Fall wäre es auch nicht mehr nötig, hunderte von .h-Files mitzuliefern, sondern alles in den Konverter einbauen. Und zu letzt stellt sich für micht noch die Frage, warum ich überhaupt noch in der Sprache X programmieren soll (bzw. X erst mal lernen soll!), wenn der Konverter nahezu alles 1:1 übersetzen , also der c-Code sehr identisch aussieht. Dann kann ich auch gleich bei C/C++ bleiben und diese merkwürdigen includes für alle möglichen Befehle verwenden.
Naja, ich würde mir dazu nochmal ein paar Gedanken machen, bevor Du anfängst.
-
Naja die neue Sprache soll hauptsächlich einfach sein. Ob da ein sauberer c++ code rauskommt ist egal... aber der c++ code soll schon gut gepflegt werden, damit da jeder durchsteigt - alles möglichst einfach. Oder magst du einen C++ code der katastrophal gecodet ist?
naja das mit 1:1 war so gesagt - es wird schon unterschiede geben - ich werde mich da auch nicht eine sprache kopieren - sondern das beste aus versch. sprachen herauspicken. Es wird schon einige Ähnlichkeiten mit C++ geben...
ja man könnte die inkludes auch in c++ benutzen - aber das wäre eine inklude-orgie (für konverter dagegen ein klacks). Zudem soll der konverter ja das erkennen: wenn funktion X funktion Y benötigt, dann wird die auch inkludiert...
Aber die IDE soll auch innovativ werden...