Vermisse Header-Dateien.
-
Bashar schrieb:
Das wäre leichter zu beantworten, wenn ich wüsste, welchen Sinn du darin siehst.
Die Leute die stdio.h geschrieben haben sahen doch auch einen Sinn
darin. Oder wurden die dazu gezwungen?Grüße,
tutorialfresser
-
TutorialFresser schrieb:
Die Leute die stdio.h geschrieben haben sahen doch auch einen Sinn
darin. Oder wurden die dazu gezwungen?Diese Header nochmal zu schreiben ist insofern sinnlos, dass es obengenannte Leute schon gemacht haben und es jeder nutzen kann. Diese Header haben sich bewährt und sind standardisiert. Würdest du versuchen die Header nachzuschreiben, wären sie garantiert fehleranfälliger. Also: sinnlos! Anders siehts aus, wenn du Header für neue Probleme schreiben willst.
gruß
xul
-
TutorialFresser schrieb:
Bashar schrieb:
Das wäre leichter zu beantworten, wenn ich wüsste, welchen Sinn du darin siehst.
Die Leute die stdio.h geschrieben haben sahen doch auch einen Sinn
darin. Oder wurden die dazu gezwungen?Grüße,
tutorialfresserDie Freigabe von Header Dateien (auschließlich) ist sinnlos, denn mit den header Dateien kann man nichts anfangen. Header Dateien sind dazu da, dem Compiler Funktionen, Makros, Strukturen, usw. vorzustellen.
Wenn du eine Bibliothek schreibst, dann musst du Header Dateien liefern, damit Nutzer (Programmier) deiner Bibliothek auf deine Bibliothel Funktionen zugreifen können. In diesem Fall werden sowohl die Bibliotheken (unter Windows DLLs, unter *nix .a bzw. .so Dateien) als auch die Header Dateien.
Nur Header Dateien macht keinen Sinn, denn was bringt dem Compiler, wenn er weiß, dass es eine Funktion void abc_schlag_mich_tot(); gibt, wenn der Linker sie nicht finden und mitlinken kann?
edit: (hab's vergessen)
die Leute, die stdio.h geschrieben haben, haben sie weder aus Spaß noch weil sie mit stdio.h Geld verdienen wollen, geschrieben, sondern weil sie es mussten. Laut ANSI C muss es eine stdio.h Datei geben, wo die grundlegende Funktion für das Input/Output (printf, scanf & co) definiert sind, die Standard FILE Strukturen stdout, stin, stderr, usw. Die Programmierung der printf Funktion geschieht aber erst in der Glibc (keine Ahnung wie die für Windows heißt). Aber stdio.h alleine ohne glibc bringt nichts.
-
Xul schrieb:
Diese Header nochmal zu schreiben ist insofern sinnlos, dass es obengenannte Leute schon gemacht haben und es jeder nutzen kann. Diese Header haben sich bewährt und sind standardisiert. Würdest du versuchen die Header nachzuschreiben, wären sie garantiert fehleranfälliger. Also: sinnlos! Anders siehts aus, wenn du Header für neue Probleme schreiben willst.
Es ist doch kein Argument, zu sagen: "Weil es das schon gibt, ist es sinnlos es nochmal zu erstellen". Wer, von den hier anwesenden, hat denn noch nie ein Programm geschrieben, das es vorher schonmal gegeben hat? Die Standardbibliothek neu zu implementieren wird übrigens immer dann (zumindest zu teilen) fällig, wenn man sie für ein neues Betriebssystem erstellt. Da reichen aber dann ja, wie Supertux schon gesagt hat, die Header nicht aus. Die Implementierung muss natürlich auch geschrieben werden.
-
ProgChild schrieb:
... ein Programm geschrieben, das es vorher schonmal gegeben hat?
Das ist etwas völlig anderes. Um sich Algorithmen oder Techniken anzueignen ist sowas legitim. Es ging aber um die (kommerzielle) Verbreitung, und da ist es sinnlos, weil:
1. Die Standardheaderdateien haben sich über Jahre bewährt, und wurden korrigiert, sofern das nötig war = Fehlerrate minimal -> selbstgeschriebene Header fehleranfälliger
2. Selbstgeschriebene Header sind nicht unbedingt standardkonform, was Inkompatiblitäten mit anderen Bibliotheken hervorrufen kann
3. Durch Optimierung (siehe 1.) werden die Standardbibliotheken meist auch effizienter sein, was Geschwindigkeit und Speicherverbrauch angeht
Aus Sicht eines Programmierers spricht das alles gegen diese selbstentwickelten Bibliotheken, weil der pratktische Nutzen (=Sinn) auf der Strecke bleibt. Man sieht doch in den Foren hier immer wieder, was für Probleme es mit nicht standardkonformen Programmen gibt. Solche Bibliotheken werden deren Lösung nicht grad fördern
mfg
Xul
-
Xul schrieb:
Das ist etwas völlig anderes. Um sich Algorithmen oder Techniken anzueignen ist sowas legitim. Es ging aber um die (kommerzielle) Verbreitung, und da ist es sinnlos
Es gibt auch Betriebssystem, die kommerziel entwickelt und verbreitet werden. Die brauchen auch die Standard C Bibliothek, die jemand implementieren muss.
Xul schrieb:
1. Die Standardheaderdateien haben sich über Jahre bewährt, und wurden korrigiert, sofern das nötig war = Fehlerrate minimal -> selbstgeschriebene Header fehleranfälliger
Es gibt nicht "die Standardheaderdateien". Es gibt einen Standard, der sagt, wie die auszusehen haben, aber nicht die Implementierung.
Xul schrieb:
2. Selbstgeschriebene Header sind nicht unbedingt standardkonform, was Inkompatiblitäten mit anderen Bibliotheken hervorrufen kann
Es ist Aufgabe der Person, die die Header implementiert, dafür zu sorgen, dass sie standardkonform sind.
Xul schrieb:
3. Durch Optimierung (siehe 1.) werden die Standardbibliotheken meist auch effizienter sein, was Geschwindigkeit und Speicherverbrauch angeht
Wo keine Standardbibliotheken exisitieren, können die auch nicht besser sein.
Xul schrieb:
Aus Sicht eines Programmierers spricht das alles gegen diese selbstentwickelten Bibliotheken, weil der pratktische Nutzen (=Sinn) auf der Strecke bleibt.
Es gibt auch keinen praktischen nutzen, wenn du ein Problem löst, das vor dir schon tausend andere Personen gelöst haben, aber zu sagen man darf alles implementieren, nur, wenn man die C Standard Bibliothek implementiert, dann ist das Sinnlos, ist doch eine schwachsinnige einteilung.
Ich bring das Beispiel jetzt noch einmal. Wenn jemand (komerziel oder nicht) ein Betriebssystem erstellt, muss er, wenn er C benutzten will, auch die C Standard Bibliothek implementieren. Er kann keine Standardheader aus der Luft zaubern.
Du kannst zwar sagen, dass es in den meisten fällen keinen Sinn macht, die Standard C Bibliothek zu implementieren, aber du kannst nicht ausschließen, dass es sinn macht, weil dann wäre sie niemals implementiert worden.
-
ProgChild schrieb:
Wenn jemand (komerziel oder nicht) ein Betriebssystem erstellt, muss er, wenn er C benutzten will, auch die C Standard Bibliothek implementieren. Er kann keine Standardheader aus der Luft zaubern.
Fällt (für mich) unter die Kategorie
Xul schrieb:
Anders siehts aus, wenn du Header für neue Probleme schreiben willst
Für ein neues OS macht es Sinn, ja!
ProgChild schrieb:
Es gibt einen Standard, der sagt, wie die auszusehen haben
Worin liegt dann der Sinn sie nochmal zu schreiben (also praktisch copy&paste damits auch dem Standard entspricht)?
ProgChild schrieb:
Es gibt auch keinen praktischen nutzen, wenn du ein Problem löst, das vor dir schon tausend andere Personen gelöst haben..
Aber einen didaktischen. Ob aber die Headerdateien nochprogrammieren der richtige Weg ist, um den Umgang mit Headerdateien zu erlernen bleibt für mich fragwürdig.
Ich verbiete ja niemandem seine eigene Math.h zu schreiben. Dennoch erscheint es mir als Zeitverschwendung, da es sie ja bereits gibt. Man muss ja das Rad nicht immer wieder neu erfinden. Und mal eine Frage an alle: Wer würde eine neue Headerdatei anstatt der mitgelieferten in ein funktionierendes System einbinden, wenn diese keine signifikanten Erweiterungen bzw. Verbesserungen enthält?
-
Xul schrieb:
Ich verbiete ja niemandem seine eigene Math.h zu schreiben. Dennoch erscheint es mir als Zeitverschwendung, da es sie ja bereits gibt.
Aber warum ziehst du gerade bei der math.h die Grenze? Es gibt so viele Dinge, die es schon gibt und trozdem neu gemacht werden. Unter anderem, um daraus zu lernen. Du könntest doch genau so gut sagen, es macht keinen Sinn, ein neues Betriebssystem für x86er zu schreiben, weil es schon eins gibt.
Es gibt sogar leute, die Assembly lernen, obwohl der C compiler welches erzeugt. Ist doch auch Zeitverschwendung
-
progchild, du musst unterscheiden zwischen lohnenswert und nicht lohnenswert.
die moegliche variation in einem math.h header ist minimal.
die moegliche variation in einem OS ist riesig.asm wuerde ich persoenlich nicht lernen, sondern eher einen compiler dafuer schreiben. denn letzteres ist wohl lohnenswerter, wenn fuer die quellsprache sowas noch nicht oder nicht in ausreichender qualitaet existiert.
-
ProgChild schrieb:
Aber warum ziehst du gerade bei der math.h die Grenze?
die math.h sollte nur als Beispiel dienen. Anderes Beispiel: ich schreib nen WinXP-Klon und verkauf ihn für das gleiche Geld = unsinnig, weil MS ein Produkt mit dem gleichen Funktionsumfang für den gleichen Preis bietet. Dazu kommt allerdings, dass die Kompatiblität zu anderen MS Produkten (und einem Großteil der Software anderer Softwareanbieter) höher ist als bei meinem Klon und dass WinXP eine größere Verbreitung und somit auch einen besseren Support durch andere User hat. Um mein OS attraktiv (=sinnig) zu machen müsste ich es um Funktionen erweitern, die WinXP nicht aufweist oder es umsonst zur Verfügung stellen. Ein schönes Beispiel dafür ist Linux (allgemein als Alternative zu Windows).
ProgChild schrieb:
Es gibt sogar leute, die Assembly lernen, obwohl der C compiler welches erzeugt. Ist doch auch Zeitverschwendung.
Der C Compiler erzeugt aber eben nicht immer optimalen ASM für bestimmte Probleme. Also kann man dadurch die Performance erhöhen (='signifikante' Verbesserung)
-
c.rackwitz schrieb:
progchild, du musst unterscheiden zwischen lohnenswert und nicht lohnenswert.
die moegliche variation in einem math.h header ist minimal.
die moegliche variation in einem OS ist riesig.Allerdings kann man bei einer neuimplementierung der Standard Bibliotheken meistens nicht einfach Copy&Paste machen, wegen den Lizenzen. Um ein sich lohnendes OS zu schreiben kann es also nötig sein, auch eine math.h zu schreiben.
c.rackwitz schrieb:
asm wuerde ich persoenlich nicht lernen, sondern eher einen compiler dafuer schreiben. denn letzteres ist wohl lohnenswerter, wenn fuer die quellsprache sowas noch nicht oder nicht in ausreichender qualitaet existiert.
Um so einen Compiler schreiben zu können, muss man aber Assembly lernen... Ohne wird das nix.
-
du musst dem compiler nur beibringen, welches mnemonic welche funktion hat. ja da muss man asm koennen, aber wer ist schon irre genug, mehr als inline asm fuer ausgesuchte stellen im code zu benutzen...
-
Xul schrieb:
ProgChild schrieb:
Aber warum ziehst du gerade bei der math.h die Grenze?
die math.h sollte nur als Beispiel dienen.
Xul schrieb:
Diese Header nochmal zu schreiben ist insofern sinnlos, dass es obengenannte Leute schon gemacht haben und es jeder nutzen kann. Diese Header haben sich bewährt und sind standardisiert. Würdest du versuchen die Header nachzuschreiben, wären sie garantiert fehleranfälliger. Also: sinnlos!
Klingt für mich wie eine allgemeingültige Aussage.
Xul schrieb:
ProgChild schrieb:
Es gibt sogar leute, die Assembly lernen, obwohl der C compiler welches erzeugt. Ist doch auch Zeitverschwendung.
Der C Compiler erzeugt aber eben nicht immer optimalen ASM für bestimmte Probleme. Also kann man dadurch die Performance erhöhen (='signifikante' Verbesserung)
Du hast erkannt, worauf ich angespielt hab
Es gibt auch Situationen in denen solche Sachen Sinn ergeben.
-
ProgChild schrieb:
Klingt für mich wie eine allgemeingültige Aussage.
Sollts eigentlich auch. math.h als repräsentatives Beispiel aus der Menge der Headerdateien. Gilt natürlich auch analog für die anderen.
ProgChild schrieb:
Es gibt auch Situationen in denen solche Sachen Sinn ergeben.
Ok, wo ist der Sinn die xxx.h für ein OS nachzuschreiben, wofür es sie schon gibt (um mal wieder auf die Ausgangsdiskussion zurückzukommen)?
-
Xul schrieb:
Ok, wo ist der Sinn die xxx.h für ein OS nachzuschreiben, wofür es sie schon gibt (um mal wieder auf die Ausgangsdiskussion zurückzukommen)?
Wenn du dir den einzigen komerziellen Compiler mit den Header Dateien für dieses OS nicht leisten kannst. Und dort mit einem günstigerem Compiler jede Menge Geld verdienen kannst.
-
ProgChild schrieb:
Wenn du dir den einzigen komerziellen Compiler mit den Header Dateien für dieses OS nicht leisten kannst. Und dort mit einem günstigerem Compiler jede Menge Geld verdienen kannst.
dürfte für die C Standard Bibliothek eher irrelevant sein. Kein OS-Entwickler wird daran interessiert sein, sein OS aufgrund fehlender Header für Programmierer und somit auch für Anwender (Mangel an Software) unattraktiv zu machen. Wenns um speziellere programmspezifische Header geht, geb ich dir allerdings Recht.
PS: Wenn ich mir den Compiler nicht leisten kann, komm ich auch schlecht an die Header ran -> kein Nachprogrammieren
-
Xul schrieb:
dürfte für die C Standard Bibliothek eher irrelevant sein. Kein OS-Entwickler wird daran interessiert sein, sein OS aufgrund fehlender Header für Programmierer und somit auch für Anwender (Mangel an Software) unattraktiv zu machen.
Das war nicht immer so.
Xul schrieb:
PS: Wenn ich mir den Compiler nicht leisten kann, komm ich auch schlecht an die Header ran -> kein Nachprogrammieren
Compiler kann man auch selber schreiben.
-
ProgChild schrieb:
Wenn du dir den einzigen komerziellen Compiler mit den Header Dateien für dieses OS nicht leisten kannst.
Fällt für mich wieder unter die Kategorie
Xul schrieb:
Anders siehts aus, wenn du Header für neue Probleme schreiben willst
Wie du aus meinem WinXP Beispiel lesen kannst, sehe ich einen OpenSource/Freeware-Clon als Alternative zu kommerzieller Software als sinnvoll für den Verbraucher an.
Xul schrieb:
Ok, wo ist der Sinn die xxx.h für ein OS nachzuschreiben, wofür es sie schon gibt (um mal wieder auf die Ausgangsdiskussion zurückzukommen)?
Ich hätte bei meiner Formulierung wohl noch 'frei zugänglich' hinschreiben müssen, ansonsten verschiebt sich ja die Sachlage.
-
Da der Thread hier in eine ganz komische Richtung abgedriftet ist (Mißverständnis häuft sich auf Mißverständnis), nochmal eine Beantwortung einer Frage von der ersten Seite:
Es macht dann Sinn, Header wie stdio.h zu schreiben, wenn man eine C-Standardlibrary implementiert. Der Threadstarter macht jedoch nicht den Eindruck als hätte er das vor, deshalb frage ich mich, was er denn dann vorhat?