Code im Speicher
-
In welchem Speicher ?
Welchen Code meinst Du ?
(Den Klartext, den Du in den Compiler "reinsteckst", oder das, was dabei herauskommt?)
-
Wenn du mit Speicher deine Textdatei meinst, dann ja
Ansonsten wird dein "Programm" durch Compilen und Linken so nach verwurstet das da höchstens noch ein Deassambler draus schlau wird --- du wirst es vermutlich nicht wiedererkennen ...
-
naja also der Code muss ja in den Hauptspeicher geladen werden.
danach wird er vom Compiler analysiert.
-
blurry333 schrieb:
naja also der Code muss ja in den Hauptspeicher geladen werden.
Genau. Da passiert eigentlich das gleiche, wie wenn du mittels eines
ifstream's eine Datei einliest und sind schlussendlich ein Haufen Zeichen hintereinander.
-
Nein, der Compiler kann den Code auch Zeichen für Zeichen lesen und sofort analysieren. Aber was ist das überhaupt für eine komische Frage?
-
eigentlich will ich nur wissen ob jedes Zeichen des Codes
ein Byte belegt ? also main würde praktisch 4 Adressen belegen ?
-
Hängt vom Charset deines Quellcodes ab.
-
Bashar schrieb:
Aber was ist das überhaupt für eine komische Frage?
Das wird bestimmt ein Tutorial und jetzt wird der Speicher erklärt.
-
Bashar schrieb:
Nein, der Compiler kann den Code auch Zeichen für Zeichen lesen und sofort analysieren.
Wie meinst du das genau?
Einzelne Zeichen von der Platte lesen? Kann ich mir ehrlich gesagt nur sehr schwer vorstellen, dass das gemacht wird..
-
Muss ich das wirklich erklären oder willst du nur Haare spalten? Der Compiler ruft einfach getchar() oder etwas äquivalentes in einer Schleife auf. Das wird natürlich meistens irgendwie gepuffert, aber wenn es dir darauf ankommt, kann der Compiler die Zeichen auch einzeln von der Tastatur lesen.
Entscheidend ist, dass absolut keine Notwendigkeit besteht, den ganzen Quelltext im Speicher zu halten.
-
Bashar schrieb:
Muss ich das wirklich erklären oder willst du nur Haare spalten? Der Compiler ruft einfach getchar() oder etwas äquivalentes in einer Schleife auf. Das wird natürlich meistens irgendwie gepuffert, aber wenn es dir darauf ankommt, kann der Compiler die Zeichen auch einzeln von der Tastatur lesen.
Entscheidend ist, dass absolut keine Notwendigkeit besteht, den ganzen Quelltext im Speicher zu halten.Also mit Haare spalten musst du nicht kommen..
Wenn das Vorgehen wirklich einen Nennenswerte Verbreitung hat, dann würde ich das gerne erklärt bekommen ja.
So weit ich das kenne kennt ein Compiler üblicherweise keine Tastatur und liest Code auch nicht direkt ein, sondern arbeitet hauptsächlich mit Dateien und diese wird er wahrscheinlich (ich habe mir keinen Source Code von den gängigen Compiler angeschaut) in den Speicher laden.Dass man es anders machen kann ist mir durchaus klar. Mein "Genau" dort ist in diesem Falle natürlich falsch, aber das wäre dann ja Haarspalterei..
-
drakon schrieb:
Wenn das Vorgehen wirklich einen Nennenswerte Verbreitung hat, dann würde ich das gerne erklärt bekommen ja.
Die erste Verarbeitungsstufe eines Compilers macht aus einem Zeichenstrom, üblicherweise, aber nicht prinzipiell zwingend, aus einer Datei gelesen, eine Liste oder einen "Strom" von Tokens, mit der bzw. dem dann weitergearbeitet wird. Wenn diese Struktur eingehalten wird, gibt es keine Notwendigkeit, mehr als das aktuelle Zeichen zu speichern. Das gerade gelesene Token vielleicht, bis man weiß, was es ist.
Aber nie das ganze Programm.So weit ich das kenne kennt ein Compiler üblicherweise keine Tastatur
Ich meine auch Standardeingabe, und als besonderes Beispiel wäre hier die Tastatur zu nennen, damit klar ist, dass der Quelltext in manchen Fällen zu keiner Zeit überhaupt als ein zusammenhängendes Objekt vorliegt.
und liest Code auch nicht direkt ein, sondern arbeitet hauptsächlich mit Dateien und diese wird er wahrscheinlich (ich habe mir keinen Source Code von den gängigen Compiler angeschaut) in den Speicher laden.
Von "gängigen" Compilern rede ich ja auch nicht.
Mir geht es ums Prinzip, insbesondere um die Verwunderung darüber, warum jemand meint, die Art und Weise, wie der Compiler den Quelltext intern speichert, würde das kleinste bisschen Verständnis zu C++ (wir sind im C++-Forum) oder sonstigen Themen liefern.
-
Bashar schrieb:
drakon schrieb:
Wenn das Vorgehen wirklich einen Nennenswerte Verbreitung hat, dann würde ich das gerne erklärt bekommen ja.
Die erste Verarbeitungsstufe eines Compilers macht aus einem Zeichenstrom, üblicherweise, aber nicht prinzipiell zwingend, aus einer Datei gelesen, eine Liste oder einen "Strom" von Tokens, mit der bzw. dem dann weitergearbeitet wird. Wenn diese Struktur eingehalten wird, gibt es keine Notwendigkeit, mehr als das aktuelle Zeichen zu speichern. Das gerade gelesene Token vielleicht, bis man weiß, was es ist.
Aber nie das ganze Programm.Du bist da eigentlich schon viel zu weit. Ich war halt noch dabei, dass man jetzt ein Programm geschrieben hat und die Dateien auf der Platte sind. Dann haut man mal einen Compiler an und der wird da mal Anfangen müssen eine Datei in den Speicher zu laden und da wird er sich die ganze Datei holen (Programm ist natürlich falsch, weil ein Programm aus mehreren Dateien bestehen kann und die müssen natürlich nicht alle gleichzeitig im Speicher sein).
Danach wird dann natürlich gewütet.So weit ich das kenne kennt ein Compiler üblicherweise keine Tastatur
Ich meine auch Standardeingabe, und als besonderes Beispiel wäre hier die Tastatur zu nennen, damit klar ist, dass der Quelltext in manchen Fällen zu keiner Zeit überhaupt als ein zusammenhängendes Objekt vorliegt.
und liest Code auch nicht direkt ein, sondern arbeitet hauptsächlich mit Dateien und diese wird er wahrscheinlich (ich habe mir keinen Source Code von den gängigen Compiler angeschaut) in den Speicher laden.
Von "gängigen" Compilern rede ich ja auch nicht.
Mir geht es ums Prinzip, insbesondere um die Verwunderung darüber, warum jemand meint, die Art und Weise, wie der Compiler den Quelltext intern speichert, würde das kleinste bisschen Verständnis zu C++ (wir sind im C++-Forum) oder sonstigen Themen liefern.Das natürlich nicht. Ich war nur von deiner Aussage verwundert. Kann aber gut sein, dass wir uns da Missverstanden haben.
