Hi Leute, der Titel sagt eigentlich schon alles, ich verstehe das Prinzip nicht ganz. Nehmen wir an ich habe ein simples C-Programm mit 3 printf-Ausgaben. Also printf ist in der Laufzeitbibliothek vom Compiler integriert als Objectcode.(soweit so richtig? :P) Was passiert jetzt beim Kompilieren bzw Linken ? Wird bei den Programm mit den angenommenen 3 printf-Ausgaben jetzt an jeder Stelle der Maschinencode von printf dafür "platziert" ? Oder wird die printf-Funktion einmal zum Programm dazugebindet und beim Ausführen in den RAM geladen und dann 3mal aufgerufen? sprich das Programm ist insgesammt kleiner. mfg
test1 schrieb: > Also printf ist in der Laufzeitbibliothek vom Compiler integriert als > Objectcode.(soweit so richtig? :P) Soweit, so gut. > Was passiert jetzt beim Kompilieren bzw Linken ? > Wird bei den Programm mit den angenommenen 3 printf-Ausgaben jetzt an > jeder Stelle der Maschinencode von printf dafür "platziert" ? Das gerade nicht. Es wird nur jeweils ein Verweis auf die Funktion in der Bibliothek gesetzt. Vorteil: Das Programm ist kleiner. Nachteil: Ohne die Bibliothek läuft das Programm nicht. Unter Windows kennt man das: Bei manchen Programmen gibts dann die Fehlermeldung: "DLL xx nicht gefunden". > Oder wird die printf-Funktion einmal zum Programm dazugebindet und beim > Ausführen in den RAM geladen und dann 3mal aufgerufen? sprich das > Programm ist insgesammt kleiner. Nein, die Funktion selbst wird nicht "dazugebindet". Nur ein Verweis auf die Funktion in der Bibliothek.
OK. von wikipedia: "Zum Beispiel benötigt die Programmiersprache C nur eine minimale Laufzeitbibliothek, schreibt aber eine große Standardbibliothek (die sogenannte Standard C Library) von Funktionen vor, die jede C-Implementation mitbringen muss." und was ist jetzt der unterschied zwischen der Laufzeitbibliothek und der Standard Library??
test1 schrieb: > und was ist jetzt der unterschied zwischen der Laufzeitbibliothek und > der Standard Library?? die Laufzeitbibliothek wird erst beim Start des Programms geladen und mit dem Hauptprogramm "verbunden" (dynamisches Linken) Standard Library bezieht sich auf Ansi-C und damit auf den Funktions- umfang und nicht auf das Linken. Beim statischen Linken wird nach dem Übersetzen die Bibliothek mit deinem Programm "verbunden" und als Ganzes abgelegt. Dynamisches Linken: Funktion1 in Laufzeitbibliothek1 wird von Prog1, Prog2 und Prog3 verwendet: Prog1, Prog2, Prog3 und Laufzeitbibliothek1 werden getrennt auf der Platte (od. aehnl.) gespeichert und beim Start von Prog1 wird Prog1 und die Laufzeitbibliothek1 in den Arbeits- speicher geladen. Statisches Linken: Funktion1 in Bibliothek1 wird von ProgA, ProgB, ProgC verwendet: Prog1 und Funktion1 aus Bibliothek1 werden zusammengebunden zu ProgA Prog2 und Funktion1 aus Bibliothek1 werden zusammengebunden zu ProgB Prog3 und Funktion1 aus Bibliothek1 werden zusammengebunden zu ProgC und auf der Platte gespeichert. Gestartet wird ProgA (bzw. B/C) D.h. Funktion1 ist anschließend in jedem ProgX vorhanden. viel Gruesse
Dieser Wikipedia-Artikel ist verwirrend. Allerdings finde ich auch den Begriff nicht sonderlich gelungen. Er führt zwangsläufig zur Verwirrung. nur so am vorbeischauen schrieb: > test1 schrieb: >> und was ist jetzt der unterschied zwischen der Laufzeitbibliothek und >> der Standard Library?? > > die Laufzeitbibliothek wird erst beim Start des Programms geladen > und mit dem Hauptprogramm "verbunden" (dynamisches Linken) Nein. Damit hat das nichts zu tun. Direkt vor dem oben zitierten Satz steht in der Wikipedia auch: "Nicht verwechselt werden darf das Konzept der Laufzeitbibliothek mit dem einer normalen Programmbibliothek, wie sie von einem Anwendungsprogrammierer erstellt oder einem Dritten geliefert wird, oder einer dynamischen Bibliothek, was eine zur Laufzeit gelinkte Programmbibliothek bezeichnet." test1 schrieb: > und was ist jetzt der unterschied zwischen der Laufzeitbibliothek und > der Standard Library?? Am Anfang des Wikipedia-Artikels steht es, wenn auch etwas schwer erkennbar: "Er [Der Begriff "Laufzeibibliothek"] bezeichnet eine spezielle Programmbibliothek, eine Sammlung von Softwarefunktionen, die benutzt wird, um innerhalb eines Computerprogramms die in eine Programmiersprache eingebauten Funktionen zur Zeit der Ausführung des Programms (Laufzeit) zu realisieren" Wichtig ist hier "_eingebaute_ Funktionen". Die Laufzeitbibliothek ist also gerade nicht die Standardbibliothek, sondern eine Bibliothek, die das implementiert, was schon in der Basis der Sprache enthalten ist, z.B. den Startup-Code, der die Funktion main() aufruft oder die Initialisierung der globalen Variablen durchführt. Bei C gibt's nicht arg viel mehr, aber bei anderen Sprachen schon. In C++ z.B. das Excpetion-Handling oder der Operator new. In manchen anderen Sprachen ist noch viel mehr in der Laufzeitbibliothek. Der obige Wikipedia-Satz zeigt auch, warum der Begriff eigentlich blöd ist. Auch andere Bibliotheken realisieren ihre Funktionen zur Laufzeit. Deshalb auch die Verwirrung hier. Ich denke, der Grund für den Namen ist, daß diese Bibliothek den Teil der Sprachbasis implementiert, der erst zur Laufzeit durchgeführt werden kann.
Eine Laufzeitbibliothek enthält Funktionen, die man nicht selbst explizit aufruft, sondern die der Compiler implizit verwendet. Beispielsweise für Multiplikation/Division und Fliesskommarechnung. Printf jedoch gehört nicht zur Laufzeitbibliothek sondern zur Standardbibliothek. Der Wiki Artikel ist auch deshalb so verwirrend, weil in Sprachen wie Fortran die I/O Bestandteil der Sprache ist, und daher die entsprechde Implementierung zur Laufzeitbibliothek zählt. In C ist das anders.
Guten Morgen, das ist eine interessante Diskussion! Ich frage mich nämlich gerade, ob diese genaue Trennung zwischen SCL (Standard C Lib) und RTL (Runtime Lib) in der Praxis immer so genau vorgenommen wird?! Ich stimme den Erklärungen von Rolf Magnus und A.K. zu, habe aber soeben noch einmal im C/C++ Kompendium von Dirk Louis nachgeschaut, da er im Anhang die eigentlich der Standard Lib zugehörigen Header in der Überschrift mit "C++-Laufzeitbibliothek" bezeichnet, was eigentlich falsch ist. Weiteres Nachlesen bei Wikipedia unter "Standard C Library" ergibt: >(Seit der Standardisierung von C muss es weder Header noch separaten >Präprozessor geben; z. B. muss der „magische“ Befehl #include stdio.h >in einem „hosted environment“ die stdio-Funktionalität ermöglichen, egal ob es >überhaupt eine Datei stdio.h gibt oder nicht.) Die tatsächliche Implementierung >der Funktionen ist meist in eine Programmbibliothek ausgelagert (z. B. libc.so.6 >unter Linux, msvcrt.dll unter Windows). und weiter unten: >Programme für Microsoft Windows nutzen häufig die von der >„Microsoft-Visual C++-Laufzeitumgebung“ („msvcrt.dll“) bereitgestellte >SCL-Implementierung, die keinen besonderen Namen trägt, da sie nicht separat >verfügbar ist. Nach meinem Verständnis komme ich dann zu dem Schluss, dass nach strenger C-Standarfdefinition die STL und RTL so zu trennen sind, wie ihr es oben beschreibt, aber durch die Eingliederung der STL in die RTL wie zum Beispiel im Falle Microsofts diese "Grenzen" etwas verwischen und die STL dann wie im o.g. Kompendium der RTL zugeordnet wird, obwohl dies im strengen Sinne eigentlich falsch wäre. Wie seht ihr das? Gruß Gunb
Gunnar B. schrieb: > Guten Morgen, > > das ist eine interessante Diskussion! Ich frage mich nämlich gerade, ob > diese genaue Trennung zwischen SCL (Standard C Lib) und RTL (Runtime > Lib) in der Praxis immer so genau vorgenommen wird?! In C? Meistens nicht. Die Trennung in Laufzeitbibliothek und Standardbibliothek ist da meistens akademischer Natur. Allenfalls wenn der Linker ein Kombilinker ist, der mit dem Output vieler verschiedener Compiler klar kommen muss/soll, wird da getrennt. Aber in früheren Zeiten war es absolut üblich, dass es einfach nur eine physische Library war (also eine einzige Datei), die vom Linker standardmässig zu einem EXE hinzugelinkt wird und aus der alle noch nicht gebundenen Funktionen eingebaut wurden. Alles was dann danach noch übrig blieb, ist ganz einfach eine "Undefined Reference". Der Linker unterscheidet da nicht was Lufzeitlibrary und was Standardlibrary ist. Für ihn sind das einfach nur Funktionsaufrufe die befriedigt werden müssen. Daher gibt/gab es auch keinen Grund, die Einzelteile da jetzt streng nach Zugehörigkeit in verschiedene Libraries zu verbannen. > Wie seht ihr das? Dass du C und C++ nicht durcheinander werfen solltest :-) Aber im großen und ganzen denke ich, dass diese Unterscheidung etwas ist, was niemandem groß Kopfzerbrechen bereiten sollte. Beim Linken baut der Linker aus einer oder mehreren Libraries noch zusätzlichen Code ins EXE ein. Den gibts in 2 Varianten: Die erste Variante ist von der Art, dass die Funktionen dokumentiert sind und in einer konformen Implementierung zur Verfügung stehen müssen. Die zweite Variante ist von der Art, dass es sich um Funktionalität handelt, die dem Compiler bekannt ist und die er benutzt und auch braucht um ein lauffähiges EXE hinzubekommen. Welcher Natur dieser 'undokumentierte Code' ist hängt von der Umgebung ab und auch davon was CPU/Compiler an Fähigkeiten mitbringen. Diese Funktionalität ist für den Compilerbauer interessant aber als ordinärer Programmierer ist das nichts was man wissen müsste.
Hallo,
Karl heinz Buchegger schrieb:
> Dass du C und C++ nicht durcheinander werfen solltest :-)
Stimmt.
Denke, die nicht korrekte Terminierung in mancher Fachliteratur sorgt
manchmal für Fragezeichen. Man möchte ja in Diskussionen die Begriffe
SCL und RTL richtig verwenden, und auch was an Funktionen dazugehört.
Das Kompendium auf meinem Schreibtisch widerspricht jedenfalls dem, was
im Netz unter SCL zu finden ist, dort steht es unter RTL. Deswegen kommt
bei mir die Frage auf, ob der Autor hier nicht ganz korrekt gewesen ist
oder ob es doch eine Begründung für dessen Zuordnung der
Standard-C-Funktionen zur C-Laufzeitumgebung kommt. Dies stände nämlich
im Widerspruch zu dem , was A.K. erklärt hat.
Meine Erklärung wäre dann mit Bezug auf Microsoft-IDEs das, was ich im
zweiten Wiki-Zitat dazu gefunden habe. Und da ist die SCL als Teil der
C++Laufzeitumgebung implementiert.
Wie auch immer, es hat mich nur mal so interessiert, am Ende stimme ich
natürlich voll zu, dass es den Normalo nicht unbedingt interessieren
braucht, was im Hintergrund im Detail passiert.
Danke für Deine Erklärung! :-)
Schönen Tag noch,
Gunb
Hi Leute Verdammt ist das verwirrend :D Ums noch verwirrender zu machen im Mikrocontroller Bereich gibts ja die AVR-libc ;) die sich ja auch Laufzeitbibliothek nennt gg aber in der sind die normalen C-Funktionen definiert oder? also auch nicht die richtige Bezeichnungg...
test1 schrieb: > Ums noch verwirrender zu machen im Mikrocontroller Bereich gibts ja die > AVR-libc ;) die sich ja auch Laufzeitbibliothek nennt gg Wo tut sie das? > aber in der sind die normalen C-Funktionen definiert oder? Die avr-libc enthält meines Wissens beides. Gunnar B. schrieb: > Ich frage mich nämlich gerade, ob diese genaue Trennung zwischen SCL > (Standard C Lib) und RTL (Runtime Lib) in der Praxis immer so genau > vorgenommen wird?! Immer mit Sicherheit nicht, aber manchmal schon. Wenn ich auf meinem Linux-System mit gcc z.B. ein C-Programm übersetze, werden unter anderem folgende Dateien mit drangelinkt: crt1.o crti.o crtbegin.o crtend.o crtn.o libgcc.a Das dürfte die Laufzeitbibliothek sein, während die Standardbibliothek in der libc.so steht. Bei C++ macht er auch eine Trennung. Der C++-spezifische Teil der Laufzeitbibliothek steht dort in der libsupc++.a, während die Standardbibliohtekt libstdc++.so heißt. Ob die jetzt wirklich so sauber getrennt sind oder Teile da auch mal in der jeweils anderen Bibliothek implementiert sind, weiß ich allerdings nicht. Letztendlich sind auch große Teile der C-Standardbibliothek im Compiler selbst schon integriert. Selbst printf und das Parsen von dessen Formatstrings beherrscht der gcc selber und kann das für Optimierungen verwenden. > Nach meinem Verständnis komme ich dann zu dem Schluss, dass nach > strenger C-Standarfdefinition die STL und RTL so zu trennen sind, wie > ihr es oben beschreibt, Würde ich nicht sagen. Dort wird das, was die Laufzeitbibliothek tut, einfach auf magische Weise getan. Wo diese Funktionalität herkommt, ist nicht weiter definiert. Es ist auch nicht verboten, sie in die Standardbibliothek mit zu integrieren, solange sie nur Namen exportiert, die, die laut C-Norm "reserved for the implementation" sind. > aber durch die Eingliederung der STL in die RTL wie zum Beispiel im > Falle Microsofts diese "Grenzen" etwas verwischen und die STL dann wie > im o.g. Kompendium der RTL zugeordnet wird, obwohl dies im strengen > Sinne eigentlich falsch wäre. Als Datei und für den Linker ist es eine einzelne Bibliothek, aber von der Funktionalität her eben zwei. Streng genommen hast du recht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.