Ich weiß, ich werde hier viele negative Bewertungen erhalten, aber dennoch möchte ich für mich einmal klären, wie man Sourcedateien bestehend aus foo.h / foo.c korrekt bezeichnet. Ich weiß sehr genau, dass das keine Bibliothek / Library ist. Für meinen "Dokumentationswahn", den ich momentan habe, würde ich das aber gerne korrekt bezeichnen (Software-Modul war mal mein Ansatz, aber so wirklich gut ist das doch auch nicht, oder?). Lustigerweise finde ich nicht so wirklich etwas im Internet. Die Arduino-Leute würde das Library nennen, aber irgendwie widerstrebt mir das. Wenn das also jemand richtig weiß, würde mir damit sehr geholfen sein!
Hallo, der Autor dieses umfangreichen Werkes nennt solche zusammen gehörenden Quelltexte "Modul". Aus solchen werden dann umfangreiche Programme zusammen gestellt. siehe Seite 50 https://www.grund-wissen.de/informatik/c/_downloads/grundkurs-c.pdf mfg
Ralph S. schrieb: > dennoch möchte ich für mich einmal klären, wie man Sourcedateien > bestehend aus foo.h / foo.c korrekt bezeichnet. > Die Arduino-Leute würde das Library nennen, aber irgendwie widerstrebt > mir das. Was ist das denn für eine Animosität? Wenn .h das Headerfile und .c die Implementierung davon ist, dann nennt man das Library oder Bibliothek. Wie soll man das sonst nennen? Ich greife vor. Oder möchte jemand behaupten das die LibStdCpp keine Library ist? Module gibt es in C nicht. Gibt es erst ab C++20 und ist abhängig von der Toolchain.
Wenn diese Dateien zusammen etwas ergeben dass man einfach benutzen kann um bestimmte Dinge damit zu erledigen könnte man "toolkit" dazu sagen. https://de.wikipedia.org/wiki/Toolkit
Veit D. schrieb: > Wenn .h das Headerfile und .c die Implementierung davon ist, dann nennt > man das Library oder Bibliothek. Kommt darauf an was der Inhalt der Dateien ist.
In C gibt es halt nicht so etwas wie beispielsweise in Pascal und was dort Units heißt. Allerdings würde ich das Konstrukt aus foo.h und foo.c schon als Library bezeichnen. Lt. Wikipedia ist ja eine Library unter C eine Funktionssammlung und foo.h/foo.c ist ja so etwas. Im Headerfile wird ja der Funktionsprototyp deklariert und dem Compiler gesagt, daß es eine Funktion Namens f mit den Parametern a, b, c .... gibt. Das ist erst mal für den Compilerlauf Deines Sourcecodes ausreichend, weil der Compiler weis, daß es diese Funktion gibt. Im C-File (oder auch mehreren) wird dann der Funktion Leben eingehaucht, sie wird definiert. Erst der Linker verbindet die Objektfiles, also Deinen eigenen Quelltext und die Objektfiles der Libs zu einem lauffähigen Ganzen. Insofern ist die Kombination foo.h/foo.c schon eine Library (im Quelltextformat). Die Kombination foo.h/foo.o würde genauso für Deinen Quelltext funktionieren. Der Unterschied ist halt, daß Du an definierten Funktionen nichts ändern kannst - zumindest nicht so einfach wie im C-Quelltext.
Veit D. schrieb: > Wenn .h das Headerfile und .c die Implementierung davon ist, dann nennt > man das Library oder Bibliothek. Na ja, ich habe mal gelernt, dass das Compilieren und sammeln in einer Objektdatei eine .a Datei ergibt, welches dann die Library ist (die somit schon compiliert ist), und der Linker sich dann aus der Bibliothek die Teile holt die er zum Builden eines Programmes benötigt. Wenn ich aber eine Quelldatei (.c) und eine Header (.h) habe und die aus nur dieser einen .c besteht und zudem noch nicht compiliert ist, soll das dann auch Library heißen. Vor einiger Zeit habe ich das getan und wurde dafür satt abgewatscht. Uwe schrieb: > Modul oder auch Unit. Unit hieß es in (Turbo)Pascal... Hans schrieb: > Die Kombination foo.h/foo.o foo.o ist ja "nur" eine einzige compilierte Objektdatei, während foo.a aus mehreren compilierten Objektdateien bestehen kann. Begriffsdefinitionen allgemeingültig zu gestalten ist bisweilen schwierig...
Hallo, jetzt wird es schwierig. ;-) .a Dateien sind doch eigentlich nur Archive die aus mehreren .o Objektdateien bestehen können. Oder nicht? Bezüglich Bibliotheken sind .a Dateien für mich vorkompilierte Bibliotheken. Es bleiben Bibliotheken. Oder nicht? Das eine ist quasi "gepackt", damit niemand reinschauen kann, dass andere sind "offene" Quelldateien die jeder einfach lesen kann. Eine offene oder geschlossene Bibliothek. So würde ich das formulieren wollen. ;-)
Veit D. schrieb: > Bezüglich Bibliotheken sind > .a Dateien für mich vorkompilierte Bibliotheken Das sind Libraries. Und nur das. In C++ gibt es auch "header-only"-Libraries, aber in C nicht.
Harald K. schrieb: > Veit D. schrieb: >> Bezüglich Bibliotheken sind >> .a Dateien für mich vorkompilierte Bibliotheken > > Das sind Libraries. Und nur das. ACK Der Vollständigkeit halber würde ich noch erwähnen wollen, daß eine Library statt auf .a auch auf .so enden kann. Dann ist es eine Shared Library. Und wenn man Linux (bzw. allgemein unixoide Betriebssysteme) verläßt, dann können die auch .lib und .dll heißen.
Angehängte Dateien:
-
Includehistorisch.png
400 KB
Historisch hat sich die Methode der Trennung in Header- und Funktions-Datei mit dem #include-Mechanismus des C-Präprozessors entwickelt. Soll so gegen 1973 passiert sein und lehnt sich wohl an ähnliche Include-mechanismen von PL/I an: https://en.wikipedia.org/wiki/C_preprocessor#History Anhang aus "Programmieren mit C" von 1990.
:
Bearbeitet durch User
... jetzt weiß ich aber immer noch nicht, wie ich die Paarung .h / .c benennen soll! Wie gesagt widerstrebt es mir, das Library zu nennen, weil korrekt nur .a eine Library ist
Axel S. schrieb: > Library statt auf .a auch auf .so enden kann Shared Libraries spielen auf embedded-Systemen die kein OS haben keine Rolle. Dynamisches Linken geht da nur sehr schwierig :-)
> ... jetzt weiß ich aber immer noch nicht, wie ich die Paarung .h / .c > benennen soll! "Paar aus C- und Headerdatei" Ja, in der heutigen Single-Gesellschaft ist der Sinn hinter der Paarbildung weitgehend vergessen.
:
Bearbeitet durch User
Ralph S. schrieb: > Uwe schrieb: >> Modul oder auch Unit. > > Unit hieß es in (Turbo)Pascal... Ja auch. Unabhängig von der Programmiersprache wird im ASPICE (https://vda-qmc.de/wp-content/uploads/2023/12/Automotive-SPICE-PAM-v40.pdf) ebenfalls von "Software unit construction" und "Software unit test" gesprochen, auf Deutsch und English ist dafür auch "Moduletest" bzw. "module test" geläufig. In meinem Umfeld ist das Verständnis so, dass der Unit-Test genau das vom TO genannte Pärchen aus c und h testet.
Ralph S. schrieb: > ... jetzt weiß ich aber immer noch nicht, wie ich die Paarung .h / .c > benennen soll! Quellcode. Modul. Es stimmt zwar, daß C keine Module oder Units kennt, wie andere Programmiersprachen. Aber die Aufteilung in Implementierung (xyz.c) und Deklaration (xyz.h) bei gleicher Namensbasis (hier: xyz) ist zumindest ein Quasi-Standard.
Bradward B. schrieb: >> ... jetzt weiß ich aber immer noch nicht, wie ich die Paarung .h / .c >> benennen soll! > > > "Paar aus C- und Headerdatei" > > Ja, in der heutigen Single-Gesellschaft ist der Sinn hinter der > Paarbildung weitgehend vergessen. Das c file bildet zusammen mit allen eingebundenen h files aus Compiler Sicht eine "translation unit" also eine Übersetzungseinheit.
Das was Du "Library" nennst sind "Precompiled libraries". Nenn es doch einfach "Library sources" wir genehmigen das!
:
Bearbeitet durch User
Ralph S. schrieb: > Lustigerweise finde ich nicht so wirklich etwas im Internet. Es gibt meines Wissens keine einheitliche Bezeichnung dafür. Das man zu einer Datei <foo>.c gerne eine Datei <foo>.h hat, die die Schnittstelle von dem was in <foo>.c ist deklariert, ist eine Konvention die sich rausgebildet hat. Eine gute, aber es gibt genug wilde Bastler die das ganz anders machen, weil sie so speziell sind. Wird .h von der .c inkludiert sind beide Dateien Teil der selben Übersetzungseinheit (translation unit). Aber das ist ein technischer Begriff der nicht die Absicht beschreibt was man mit der .c, .h Kombination erreichen will, sondern nur was der eigentliche Compiler sieht. Ist die Absicht hinter einer .c, .h Kombination so etwas wie ein Modul bereit zu stellen, dann kann man die Kombination von mir aus Modul nennen. Egal ob die Sprache dafür nicht direkt Konstrukte anbietet. Ich würde sogar Sourcecode Library (Quelltext-Bibliothek) durchgehen lassen, wenn das die Absicht hinter einer solchen Kombination ist. Besonders im Embedded-Bereich wo Quelltext-Bibliothek schon mal häufiger auftauchen als reine Objektcode-Bibliotheken[1]. > Die > Arduino-Leute würde das Library nennen, aber irgendwie widerstrebt mir > das. Das war auch schon lange vor Arduino so. Auch wenn ich den Arduino-Copy-Paste-Clowns gerne mal in den Arsch trete, liegen sie mit der Bezeichnung Library nicht so falsch, wenn die Kombination wirklich eine Sourcecode Library darstellen soll. > Wenn das also jemand richtig weiß, würde mir damit sehr geholfen sein! In der Technik hat bei weitem nicht alles einen festen, etablierten Namen. Ist halt so. Wenn man für eine Anwendung einen Namen braucht behilft man sich damit, dass man am Anfang eine eigene Definition gibt. _ [1] Aufgrund der Vielzahl von Konfigurationsmöglichkeiten (z.B. Pin-Zuweisungen), die man aus Resource- und Performance-Gründen gerne hart rein kompiliert statt sie zur Laufzeit variabel zu halten.
Hi Leute, also ich würde einfach schreiben: C-Quelldatei und zugehörige Include/Header Datei. Wieso muss es unbedingt eine Bezeichnung für die beiden zusammen geben? Außerdem ist es ja nicht selbstverständlich, dass es zu jeder Quelldatei auch eine (gleichnamige) Include-Datei gibt. Im Gegenteil, oft werden die Deklarationen für viele Funktionen in einer einzigen Header-Datei untergebracht, und jede einzelne Funktionsdefinition in einer einzelnen Quelldatei (jedenfalls in C, in C++ sieht die Sache bei Klassen ein wenig anders aus, dort gibt es andere "good practices"). ciao Marci
Nenn es doch Ehepaar. Der Mann ist die .h Datei. Der bestimmt was passiert und erzeugt die Außenwirkung. Die Frau ist die .c Datei. Die macht die ganze Arbeit.
> C-Quelldatei und zugehörige > Include/Header Datei. Wieso muss es unbedingt eine Bezeichnung für die > beiden zusammen geben? > > Außerdem ist es ja nicht selbstverständlich, dass es zu jeder Quelldatei > auch eine (gleichnamige) Include-Datei gibt. > Im Gegenteil, oft werden > die Deklarationen für viele Funktionen in einer einzigen Header-Datei > untergebracht, Sehe ich ähnlich, es gibt Szenarien, da gibt es nur eine val.h Datei und keine val.c Datei sondern val.h wird von h20.c und mn2O4. eingebunden/inkludiert. Beispiel: Registernamen und Adressen von einzelnen Mikrocontrollern http://www.elde.cz/datasht/AVR32000%20Introduction%20to%20AVR32%20header%20files.pdf Oder eben (verständliche) Namen für die Pins wie in der avr/portpins.h . Vielleicht will man noch unterscheiden, ob in der .h datei nur Typdeklarationen, Konstanten stehen oder auch Prototypen für Funktionsaufrufe (mit denen der Compiler checkt ob die Typen beim Aufruf und Deklaration passen (obwohl das den Compilern die nicht type-streng sind, eigentlich egal ist, wodurch man nette Sicherheits-Schweinerein machen kann)). Historisch gesehen ist "library" wenig passend, weil in der toolchain um librarys der "ar" (archivier) kümmert und nicht der "cpp" (präprozessor). https://agustinespinoza.medium.com/c-program-compilation-process-6452628f275d https://linux.die.net/man/1/ar Man könnte auch den beliebten "Topf-Deckel" Vergleich heranziehen. Der header ist halt der Deckel der mehreren Töppen passt. Und über den Inhalt des Topfes, also das was untern Deckel ist, wird (fast) nichts gesagt.
:
Bearbeitet durch User
Marci W. schrieb: > also ich würde einfach schreiben: C-Quelldatei und zugehörige > Include/Header Datei. Wieso muss es unbedingt eine Bezeichnung für die > beiden zusammen geben? Weil es in einer Dokumentation mühsam ist, jedes mal "die C-Quelldatei und zugehörige Include/Header Datei" zu schreiben
Ralph S. schrieb: > Weil es in einer Dokumentation mühsam ist, jedes mal "die C-Quelldatei > und zugehörige Include/Header Datei" zu schreiben Man nennt das einfach Quelltext. Daß das zwei Dateien sind, muss man nicht jedes Mal erwähnen; wer C kennt (und nicht glaubt, daß das, was in der Arduino-Welt gemacht wird, tonangebend wäre), wer sich schon mal angesehen hat, wie eine C-Toolchain arbeitet, der kommt damit klar, und der verwehrt sich deutlich dagegen, den Begriff "Library" zu nutzen. Der ist, auch wenn einige hier im Thread das gerne anders sähen, klar definiert - eine Library ist das, was dem Linker vorgeworfen wird, und verwendet wird, um noch nicht aufgelöste Symbole in den einzelnen Objektdateien zu befriedigen. Libraries heißen meistens libXXX.a und werden dem Linker mit -lXXX bekanntgegeben; es gibt aber auch andere Toolchains, bei denen Libraries XXX.lib heißen, oder auch komplett andere Namen tragen. Library-Quelltext ist das, was nach dem Übersetzen eine solche Library zur Folge hat.
Ralph S. schrieb: > Marci W. schrieb: >> also ich würde einfach schreiben: C-Quelldatei und zugehörige >> Include/Header Datei. Wieso muss es unbedingt eine Bezeichnung für die >> beiden zusammen geben? > > Weil es in einer Dokumentation mühsam ist, jedes mal "die C-Quelldatei > und zugehörige Include/Header Datei" zu schreiben Na dann mach ein Kapitel "Notation" und schreib da "Im folgenden wird die Kombination aus Header- und Quellcode-Datei als Modul bezeichnet. Wenn im Text vom foo-Modul gesprochen wird, bezeichnet das die Dateien /foo.h/ und /foo.c/." Fertig.
Eine Namensgebungsalternative wäre, statt einfach von "Quelltext" oder "Modul" oder "den Dateien da" zu reden, die Funktion zur Namensgebung heranzuziehen. Im Embedded-Bereich hat man viel mit Treibern zu tun, das ist Quelltext, der die Ansteuerung bestimmter Hardware übernimmt. So kann man schreiben "Der GPIO-Treiber verbirgt sich in blafusel.c/.h und wird wie folgt verwendet ..." Und im folgenden wird das Ding weiterhin einfach als "GPIO-Treiber" bezeichnet.
Die foo.h enthält keinen Code (belegt keinen Flash und keinen RAM). Sie macht nur die Symbole einer Lib bekannt, damit sie von anderen Modulen aus benutzt werden können. Die foo.c enthält dann den Code und die Variablen dazu, d.h. belegt Ressourcen. Früher waren Rechner sehr langsam, daher hat man Libs vorkomiliert (foo.obj) und in Archiven gesammelt (foo.a). Die Archive waren so angelegt, daß nicht benötigter Code auch nicht gelinkt wurde. Heutzutage sind die PCs rattenschnell, daher compiliert man oft alles in einem Rutsch immer wieder neu. Auch können die Compiler selber schon toten Code eliminieren. Auch werden Libs oft nicht mehr sorgfältig getestet, d.h. als grüne Bananen ausgeliefert. Da ist es von Vorteil, wenn der Anwender Fehler finden und Korrekturen direkt vornehmen kann.
WENN das der komplette Sourcecode einer library ist, DANN könnte man das als (Sourcecode-)library bezeichnen. Der Dokumentation dazu ist das aber doch völlig egal, ob die library im Source- oder im Objectcode vorliegt. Das headefile brauchts ja eh immer im Sourcecode. Oliver
Ralph S. schrieb: > Software-Modul war mal mein Ansatz Thomas Z. schrieb: > Modul Christian S. schrieb: > der Autor dieses umfangreichen Werkes nennt solche zusammen gehörenden > Quelltexte "Modul". Aus solchen werden dann umfangreiche Programme > zusammen gestellt. Uwe schrieb: > Modul Veit D. schrieb: > Module gibt es in C nicht. Gibt es erst ab C++20 und ist abhängig von > der Toolchain. Axel S. schrieb: > Modul. Hannes J. schrieb: > Ist die Absicht hinter einer .c, .h Kombination so etwas wie ein Modul > bereit zu stellen, dann kann man die Kombination von mir aus Modul > nennen. +1 Ich würde es ebenfalls Modul nennen. Die Kombination einer .c- und .h-Datei entspricht in der Softwareentwicklung in etwa einer Baugruppe eines elektronischen Geräts, die ebenfalls als Modul bezeichnet wird. Siehe auch hier: https://de.wikipedia.org/wiki/Modul_(Software) Natürlich ist ein solches C-Modul nicht exakt dasselbe wie ein Modul in Modula, Free Pascal oder C++ (vor allem die Implementierung ist anders und es ist nicht als festes Feature in der Sprachdefinition verankert). Es wird aber meist in der gleichen Weise verwendet, weswegen die Bezeichnung "Modul" IMHO durchaus legitim ist. Da es in C nur diese eine Form von Modulen gibt, besteht auch keine Verwechslungsgefahr. Je nach Domäne haben Begriffe eben oft unterschiedliche Bedeutungen. So sind die Module im Linux-Kernel zwar C-Module, haben aber zusätzliche spezifische Eigenschaften. Ein SAP-Modul ist wieder etwas anders. Module gibt es darüberhinaus auch in der Mathematik und bei Zahnrädern ... Das ist aber alles kein Problem, wenn innerhalb eines vorliegenden Kontextes die Definition eindeutig ist. Um dich von anderen Definitionen des Modulbegriffs klarer abzugrenzen, kannst du ja folgendes tun: Axel S. schrieb: > Na dann mach ein Kapitel "Notation" und schreib da "Im folgenden wird > die Kombination aus Header- und Quellcode-Datei als Modul bezeichnet. Ich finde "Modul" auch passender als "Bibliothek". Als Bibliothek würde ich eine Sammlung von Modulen bezeichnen, bei der zudem ein Schwerpunkt auf Mehrfachverwendung gelegt wird, die bei einem Modul nicht unbedingt gegeben sein muss.
Peter D. schrieb: > Die foo.h enthält keinen Code (belegt keinen Flash und keinen RAM). Das war mal so, aber in "inline" Zeiten gibt es durchaus (auch in C) "Module", die nur aus einer Header Datei bestehen. Da die ursprüngliche Aufgabentrennung von h und c aufgeweicht ist, nutze ich fast nur den Begriff "Modul". Manchmal nur eine h Datei, manchmal h+c, manchmal h+c+c... Wenn es größer wird halt "Package" oder "Library". Je nach Auslieferungsvariante....
Hallo, wenn ihr wollt könnt ihr das Modul nennen. Ich gebe nur eins zu bedenken. Ihr erfindet das Rad neu und tragt dazu bei einen neuen Begriff einzuführen wofür es einen Begriff schon gibt. Nämlich Bibliothek. Ganz klares Beispiel. Ich meine was ist denn die StdLibCpp? Das ist eine Standard Bibliothek und wird schon seit Jahrzehnten genauso benannt - eine Bibliothek. Es kam noch niemanden in den Sinn es Modul zu nennen. Wenn ich in eine echte Bibliothek gehe, würde niemand auf die Idee kommen zu sagen ich gehe in ein Modul und leihe mir ein Buch aus. Ich möchte nur sagen - Vorsicht mit neuen Begrifflichkeiten.
Ja richtig. Wenn der Autor des Moduls ihm einen Namen mit "Standard" und "Library" gegeben hat, dann hatte er Wiederverwendung im Sinn, und ich würde ich das Modul auch Bibliothek nennen. Wenn es aber ein C+H ist, was projektspezifisch ist, fehlt mir zur Bibliothek der Wiederverwendungsgedanke.
:
Bearbeitet durch User
Veit D. schrieb: > Ich meine was ist denn die StdLibCpp? > Das ist eine Standard Bibliothek und wird schon seit Jahrzehnten genauso > benannt - eine Bibliothek. Die gibts aber nicht im Sourcecode. Oliver
Embarcadero nennt das *.h und *.CPP Paar in allen seinen Unterlagen "Unit". Daraus ensteht dann nach Compilierung die Objektdatei *.obj. Mehere Objektdateien werden dann zur Bibliothek zusammengefaßt *.lib, wenn man statisch linken will. Eine DLL ermöglicht dynamisches Binden, entweder beim Starten der Anwendung oder später. Ein Package ist eine spezielle DLL, die auf Grund ner verbesserten Struktur im Programm dann leichter anzusprechen ist als ne DLL. Ein Package funktioniert aber nur im Emba-Universum, während ne DLL auch von anderen Sprachen gelinkt werden kann. mfg
:
Bearbeitet durch User
Oliver S. schrieb: > Veit D. schrieb: >> Ich meine was ist denn die StdLibCpp? >> Das ist eine Standard Bibliothek und wird schon seit Jahrzehnten genauso >> benannt - eine Bibliothek. > > Die gibts aber nicht im Sourcecode. Hallo, ich möchte nicht anfangen zu unterscheiden ob sie vorkompiliert ist oder nicht. Das spielt für die Verwendung keine Rolle. Ansonsten tue ich mich echt schwer euren Argumenten zu folgen. Ob nun Projektspezifisch oder nicht. Oder die Größe der "Dateisammlung". Auch das sollte für die Begrifflichkeit keine Rolle spielen. Ich gehe in der Betrachtung nicht so tief rein wie manch anderer. Ansonsten müßte man Hunderte Unterscheidungen behandeln und Hunderte Begriffe definieren. Überspitzt gesagt. Das möchte hoffentlich niemand. Ich will darauf nicht weiter rumreiten. Ich lese noch mit und jeder findet seine Meinung. So ist das eben. ;-)
Lotta . schrieb: > während ne DLL auch von anderen Sprachen gelinkt werden kann. Kommt drauf an, wie und mit was die DLL compiliert worden ist. Ob sie nun den Windowskonventionen (STDCALL) oder den C-Konventionen (CDECL) folgt. Meines Wissens gehen die Aufrufparameter bei CDECL von rechts nach links, also umgekehrt. Das sollte man berücksichtigen.
Heinz B. schrieb: > Lotta . schrieb: >> während ne DLL auch von anderen Sprachen gelinkt werden kann. > > Kommt drauf an, wie und mit was die DLL compiliert worden ist. > Ob sie nun den Windowskonventionen (STDCALL) oder den C-Konventionen > (CDECL) folgt. Meines Wissens gehen die Aufrufparameter bei CDECL von > rechts nach links, also umgekehrt. > > Das sollte man berücksichtigen. Dazu kommt dann die Schwierigkeit Klassen in DLLs zu halten und anzusprechen. Und dann die dämlichen "Zeiger auf Funktionen" beim Aufruf beim dynamischen Laden. :-P Packages haben deshalb innerhalb des Emba-Universums ( man kann gemischt in C++ und Pascal proggen ) die DLLs praktisch ersetzt. mfg
Veit D. schrieb: > Wenn ich in eine echte Bibliothek gehe, würde niemand auf die > Idee kommen zu sagen ich gehe in ein Modul und leihe mir ein Buch aus. Ich habe aber auch noch niemanden gesehen, der mit einer echten Bibliothek gelinkt hat ;-) > Ich möchte nur sagen - Vorsicht mit neuen Begrifflichkeiten. Es geht hier weniger um alt oder neu, sondern – wie ich oben geschrieben habe – um die Domäne, in dem die Begriffe verwendet werden. Das betrifft das "Modul" ebenso wie die "Bibliothek". Ein lustiger Begriff in diesem Zusammenhang ist auch der "Funktor", der in der Programmierung mindestens drei völlig verschiedene Bedeutungen hat (bspw. in Prolog, C++ und Haskell). Außerhalb der Programmierung gibt es sogar noch weitere. Wird der Begriff aber innerhalb einer Domäne (bspw. in einer Gruppe von Prolog-, C++ oder Haskell-Programmieren) verwendet, ist jedem Beteiligten sofort klar, was damit gemeint ist. Im Vergleich dazu sind sich ein C-Modul (bestehend aus einer .c/.o- und .h-Datei) und einem Free-Pascal-Modul schon sehr ähnlich, denn beide haben als wesentliche Bestandteile eine Implementierung und eine Interface-Beschreibung und werden in gleicher Weise angewandt. Warum sollte man dann nicht auch den gleichen Begriff dafür verwenden?
Yalu meinte: > Im Vergleich dazu sind sich ein C-Modul (bestehend aus einer .c/.o- und > .h-Datei) und einem Free-Pascal-Modul schon sehr ähnlich, denn beide > haben als wesentliche Bestandteile eine Implementierung und eine > Interface-Beschreibung und werden in gleicher Weise angewandt. Warum > sollte man dann nicht auch den gleichen Begriff dafür verwenden? noch besser wäre es, wenn man sich endlich auf ein gemeinsames Objektcodeformat einigen könnte, wenigstens unter Windows oder Linux. So ähnlich wie in der KI, wo sich langsam durchsetzt die Modelle im gguf - Format auszuliefern. Umarme mein Gesicht!! ;-P
Veit D. schrieb: > Ihr erfindet das Rad neu und tragt dazu bei einen neuen > Begriff einzuführen wofür es einen Begriff schon gibt. > Nämlich Bibliothek. Ganz klares Beispiel. > Ich meine was ist denn die StdLibCpp? Weiß ich nicht. Meinst du vielleicht die GNU libstdc++? Das ist eine "echte" Library:
1 | ~ $locate libstdc++ | grep /usr/lib |
2 | /usr/lib/gcc/i586-linux-gnu/4.8/libstdc++.a |
3 | /usr/lib/gcc/i586-linux-gnu/4.8/libstdc++.so |
4 | /usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.a |
5 | /usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.so |
6 | /usr/lib/gcc/x86_64-linux-gnu/4.8/libstdc++.a |
7 | /usr/lib/gcc/x86_64-linux-gnu/4.8/libstdc++.so |
8 | /usr/lib/gcc/x86_64-linux-gnu/4.9/libstdc++.a |
9 | /usr/lib/gcc/x86_64-linux-gnu/4.9/libstdc++.so |
10 | /usr/lib/i386-linux-gnu/libstdc++.so.6 |
11 | /usr/lib/i386-linux-gnu/libstdc++.so.6.0.20 |
12 | /usr/lib/vmware/lib/libstdc++.so.6 |
13 | /usr/lib/vmware/lib/libstdc++.so.6/libstdc++.so.6 |
14 | /usr/lib/x86_64-linux-gnu/libstdc++.so.6 |
15 | /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20 |
Guckstu? Alles .a und .so (und Symlinks darauf). Für 99% aller Anwender ist die libstdc++ einfach eine weitere vorcompilierte Library. Daß diese Library (auch) im Quellcode vorhanden ist, liegt lediglich daran daß sie als Bestandteil der GCC natürlich auch Open Source ist. Dennoch verwenden die meisten Anwender die Library als Input für den Linker und nicht, wie es für Quellcode normal wäre, für den Compiler. Es gibt auch für Open Source einen klare Unterscheidung zwischen Quellcode und Library. Ich finde es löblich, daß Ralph S. diese Unterscheidung aufrecht erhalten will.
Oliver S. schrieb: > WENN das der komplette Sourcecode einer library ist, DANN könnte man das > als (Sourcecode-)library bezeichnen. Wohl eher als Library-Sourcecode ;-)
Hi Leute, ich frage mich so langsam, in welchem Zusammenhang man ein Gespann aus Quelltext- und Header-Datei mit einem Begriff benennen sollte!? Ich habe auch schon dokumentiert, aber die Notwendigkeit, diese Kombination explizit als Paar benennen zu müssen, ergab sich bislang nicht. Und egal wie man das Kind letztendlich auch benennen mag, ohne vorherige Definition wird es beim Leser Missverständnisse geben. ciao Marci
> Weil es in einer Dokumentation mühsam ist, jedes mal "die C-Quelldatei > und zugehörige Include/Header Datei" zu schreiben Sorry, aber solange man die Doku nicht schweisstreibend mit Stein und Meisel in Granit schlagen muss, ist das blödeste Begründung ever. Die kommt dann von Personen, die wegen individuellen "Tippproblemen" nur "kryptische" drei-Zeichen-lange Variablennamen verwenden, weil die Verwendung aussagekräftiger identifier "mühsam" ist. Und seit über 30 Jahren gibt es die Möglichkeit sich die Tipparbeit durch Verwendung von Makros oder simplen "Suchen und Ersetzen" zu erleichtern. https://de.wikipedia.org/wiki/Makro#Makros_in_Anwendungsprogrammen Ich meine, "früher" ist man beispielsweise mit den erwähnten Präprozessor oder sed über die .tex-sourcen gegangen um die selbst gewählten Abkürzungen/Token auszuschreiben. Und ja, auch das Erlernen des 10-Finger-(blind)-Schreibens oder anderer effizienter Texteingabetechniken macht "Mühe". Es macht aber auf längere Sicht einfacher, ausführliche und hilfreiche Texte zu verfassen.
:
Bearbeitet durch User
Axel S. schrieb: > Alles .a und .so (und Symlinks darauf)
1 | > file /usr/lib/libstdc++.a |
2 | /usr/lib/libstdc++.a: current ar archive |
3 | > file /usr/lib/libstdc++.so |
4 | /usr/lib/libstdc++.so: symbolic link to libstdc++.so.6.0.34 |
5 | > file /usr/lib/libstdc++.so.6.0.34 |
6 | /usr/lib/libstdc++.so.6.0.34: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=90..., with debug_info, not stripped |
Aber ja, die .a und .so würde ich auch als Library bezeichnen. Im Quellcode dürfte die libstdc++ auch auf viele Dateien aufgeteilt sein.
Bradward B. schrieb: > Die kommt dann von Personen, die wegen individuellen "Tippproblemen" nur > "kryptische" drei-Zeichen-lange Variablennamen verwenden, weil die > Verwendung aussagekräftiger identifier "mühsam" ist. da sind sie wieder, die "Mutmaßer" und "Untersteller". Natürlich verwende ich nur "kryptische" drei-Zeichen-lange Variable- und Funktionsnamen wie man in Beitrag "CH32V003: Selbstbauprogrammer und "Getting started"" sehen kann. Und gerade schreibe ich an der Erweiterung der Doku zu einer "C-Quell- und dazugehörenden Include/Header Datei" namentlich "st77xx_display_v2.c / .h". Und natürlich verwende ich so kryptische Funktionsnamen wie "putpixel" und "outtextxy". Ach so, du hast ja von Variablennamen geredet und da verwende ich dann tatsächlich Variable wie "x" und "y" anstelle von "x_koordinate" und "y_koordinate". Und vor allen Dingen die unsägliche Variable "i", die ja wirklich nichts aussagt (da spielt es dann natürlich auch keine Rolle, dass andere Variable bspw. "textcolor" heißen). Bradward B. schrieb: > weil die > Verwendung aussagekräftiger identifier "mühsam" ist. Mühselig ist ein Aussagekräftiger Identifier tatsächlich bisweilen, aber nicht das Schreiben eines langen Begriffes, sondern das Finden eines bezeichnenden Namens wie bspw. "rgbfromvalue" (Funktion, das einen 16-Bit rot-grün-blau Wert aus 3 einzelnen 8-Bit Farbwerten erzeugt, oder anderst herum aus einem RGB888 einen RGB565 Wert produziert) Natürlich hätte man das auch "RGB888_to_RGB565" nennen können. Andererseits gibt es auch so etwas wie "rgbfromega", die hätte dann wohl heißen sollen: "get_rgb565_from_ega_palette"?. Bisweilen kann das dann tatsächlich mühselig sein. Aber das allerbeste der Unterstellungen ist das hier: Bradward B. schrieb: > Und ja, auch das Erlernen des 10-Finger-(blind)-Schreibens oder anderer > effizienter Texteingabetechniken macht "Mühe". Es macht aber auf längere > Sicht einfacher, ausführliche und hilfreiche Texte zu verfassen. Zum einen, ungeachtet der Tatsache, dass ich sehr wohl 10-Finger-(blind) schreiben kann: was hat das mit einem technischen Forum zu tun. Ich glaube, dass hier der überwiegende Teil, der hier unterwegs ist und programmiert, auf der Tastatur sehr schnell ist. Ansonsten könnte man keinen umfangreicheren Programme schreiben. Aber selbst wenn man dort langsam wäre, was hat das mit einer Dokumentation oder dem Programmieren zu tun? By the way: Bradward B. schrieb: > Ich meine, "früher" ist man beispielsweise mit den erwähnten > Präprozessor oder sed Ich kenne "sed" und für mich ist das nicht "früher", denn als bekennender Absolut-Fan der Konsole in Linux verwende ich das bis heute! Außerdem: Es gab Zeiten, da war ich mit meinen 600 Zeichen/Minute deutlich schneller als die Schreibkräfte an meiner Arbeitsstelle. Von daher: Ich "liebe" solche hochqualifizierten Kommentare wie Deinen! Bradward B. schrieb: > Ich meine, "früher" ist man beispielsweise mit den erwähnten > Präprozessor oder sed -------------------------------------------------------------- Zurück zum Thema: Jetzt habe ich hier vieles sehr häufig gelesen, smile, aber "schlauer" bin ich jetzt dennoch nicht wie ich etwas in Zukunft schreibe. Eine Begriffsdefinition am Eingang eines Textes wie etwas zu verstehen ist, erscheint mir wohl am Sinnvollsten Marci W. schrieb: > Und egal wie man das Kind letztendlich auch benennen mag, ohne > vorherige Definition wird es beim Leser Missverständnisse geben. Das stimmt wohl.
Ich seh hier keine Unterstellung und frage mich warum Du das auf Dich beziehst. War ne simple Meinungsäußerung zum Thema und keine Kritik an Dir. Trink erstmal einen Kaffee und entspann Dich.
Yalu X. schrieb: > Ich habe aber auch noch niemanden gesehen, der mit einer echten > Bibliothek gelinkt hat ;-) Früher zu DOS - Zeiten war sowas doch oft üblich.
1 | Clipper myprog.prg |
2 | Link myprog.obj -lib clipper.lib ,[weitere libs] |
Konnte man mit verschiedenen Linkern linken. Da genügte auch der MS-DOS Linker Link.exe, der mal eine zeitlang standardmäßig bei MS-DOS dabei war. Mit einer entsprechenden .bat Datei ging das wunderbar. Der MASM und Quickbasic nutzten den Linker auch. Heutzutage wird das oft nur versteckt. Entweder ruft der Compiler nach dem Compilieren den Linker selbständig auf oder hat ihn sogar schon integriert. Wird auch oft bei Nischensprachen so gemacht.
:
Bearbeitet durch User
Heinz B. schrieb: > Yalu X. schrieb: >> Ich habe aber auch noch niemanden gesehen, der mit einer echten >> Bibliothek gelinkt hat ;-) > > Früher zu DOS - Zeiten war sowas doch oft üblich. Das bezog ich auf die von mir zitierte Aussage von Veeit, die ich hier noch einmal wiederhole: Veit D. schrieb: > Wenn ich in eine echte Bibliothek gehe, würde niemand auf die > Idee kommen zu sagen ich gehe in ein Modul und leihe mir ein Buch aus. Mit der "echten" Bibliothek meint er offensichtlich eine mit Büchern zum Ausleihen und eben keine Programmbibliothek.
:
Bearbeitet durch Moderator
wie wäre es mit: codeschnipsel im prinzip kann es ja alles sein, erst durch die bestimmung des sourcecodes kann man dem kind einen namen geben. es kann eine lib sein, ein modul, ein plugin eine anwendung, ein example, was auch immer, erst der inhalt kann die definition liefern.
Heinz B. schrieb: > Kommt drauf an, wie und mit was die DLL compiliert worden ist. > Ob sie nun den Windowskonventionen (STDCALL) oder den C-Konventionen > (CDECL) folgt. Meines Wissens gehen die Aufrufparameter bei CDECL von > rechts nach links, also umgekehrt. Du kannst beide Varianten in einer DLL mischen. Zumindest unter Delphi ist das so. Da schreibt man einfach hinter die Deklaration einer Funktion stdcall. Also so:
1 | function summe(a, b: integer):integer;stdcall; |
Alles andere wäre dann CDECL
Veit D. schrieb: > Wenn ich in eine echte Bibliothek gehe, würde niemand auf die > Idee kommen zu sagen ich gehe in ein Modul und leihe mir ein Buch aus. Wenn du in ein Gebäude gehst, in dem sich nur ein einziges Paar zweier zusammengehöriger Bücher befindet, würde niemand auf die Idee kommen zu sagen, du gingest in eine Bibliothek. Eine galvanische Zelle besteht aus einem einzigen zusammengehörenden Paar von Anode und Kathode. Eine Batterie ist es aber nicht, denn die besteht aus mehr als einer Zelle. Eine Bibliothek ist eine Sammlung aus einer nicht geringen Anzahl von Büchern, sonst ist es keine. Vergleiche auch Mediathek: Ein Video mit zugehöriger Audiospur ist keine Mediathek.
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.