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!
der Autor dieses umfangreichen Werkes nennt solche zusammen gehörenden Quelltexte "Modul". Aus solchen werden dann umfangreiche Programme zusammen gestellt.
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.
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.
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.
.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. ;-)
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.
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
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.
... 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.
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.
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").
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.
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)).
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.
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
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.
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.
der Autor dieses umfangreichen Werkes nennt solche zusammen gehörenden
Quelltexte "Modul". Aus solchen werden dann umfangreiche Programme
zusammen gestellt.
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.
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:
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.
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.
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.
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. ;-)
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.
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.
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?
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.
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.
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.
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.
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.
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
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).
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:
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?
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
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.
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.
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:
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.
