Forum: Mikrocontroller und Digitale Elektronik Wie nennt man eine .h / .c Kombination von Quelldateien?


von Ralph S. (jjflash)


Lesenswert?

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!

von Oliver S. (oliverso)


Lesenswert?

Sourcecode…

Oliver

von Thomas Z. (usbman)


Lesenswert?

Modul

von Christian S. (roehrenvorheizer)


Lesenswert?

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

von Uwe (uhi)


Lesenswert?

Modul oder auch Unit.

von Veit D. (devil-elec)


Lesenswert?

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.

von Udo S. (urschmitt)


Lesenswert?

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

von Alexander (alecxs)


Lesenswert?

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.

von Hans (ths23)


Lesenswert?

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.

von Ralph S. (jjflash)


Lesenswert?

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...

von Veit D. (devil-elec)


Lesenswert?

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. ;-)

von Harald K. (kirnbichler)


Lesenswert?

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.

von Axel S. (a-za-z0-9)


Lesenswert?

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.

von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Angehängte Dateien:

Lesenswert?

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
von Ralph S. (jjflash)


Lesenswert?

... 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

von Ralph S. (jjflash)


Lesenswert?

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 :-)

von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Lesenswert?

> ... 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
von Uwe (uhi)


Lesenswert?

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.

von Axel S. (a-za-z0-9)


Lesenswert?

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.

von Hans-Georg L. (h-g-l)


Lesenswert?

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.

von Alexander (alecxs)


Lesenswert?

Das was Du "Library" nennst sind "Precompiled libraries". Nenn es doch 
einfach "Library sources" wir genehmigen das!

: Bearbeitet durch User
von Hannes J. (Firma: _⌨_) (pnuebergang)


Lesenswert?

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.

von Marci W. (marci_w)


Lesenswert?

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

von Peter (pittyj)


Lesenswert?

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.

von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Lesenswert?

>  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
von Ralph S. (jjflash)


Lesenswert?

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

von Harald K. (kirnbichler)


Lesenswert?

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.

von Axel S. (a-za-z0-9)


Lesenswert?

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.

von Harald K. (kirnbichler)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

von Oliver S. (oliverso)


Lesenswert?

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

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von Klaus H. (klummel69)


Lesenswert?

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....

von Veit D. (devil-elec)


Lesenswert?

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.

von Uwe (uhi)


Lesenswert?

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
von Oliver S. (oliverso)


Lesenswert?

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

von Lotta  . (mercedes)


Lesenswert?

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
von Veit D. (devil-elec)


Lesenswert?

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.  ;-)

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

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.

von Lotta  . (mercedes)


Lesenswert?

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

von Yalu X. (yalu) (Moderator)


Lesenswert?

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?

von Lotta  . (mercedes)


Lesenswert?

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

von Axel S. (a-za-z0-9)


Lesenswert?

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.

von Marci W. (marci_w)


Lesenswert?

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 ;-)

von Marci W. (marci_w)


Lesenswert?

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

von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Lesenswert?

> 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
von Rick (rick)


Lesenswert?

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.

von Ralph S. (jjflash)


Lesenswert?

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.

von Alexander (alecxs)


Lesenswert?

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.

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

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
von Yalu X. (yalu) (Moderator)


Lesenswert?

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
von Oliver D. (unixconf)


Lesenswert?

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.

von Hans (ths23)


Lesenswert?

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

von Rolf (rolf22)


Lesenswert?

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.

Bitte 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
Noch kein Account? Hier anmelden.