Wieso kamen die Leutz auf die Idee bei den C++ Standardheader keine Endung zu nehmen
-
Die Dateiendungen sind doch nur für den User da. Jedem Programm sollte doch egal sein, wie das File heißt. Es muss doch nur die Daten die drin stehen so behandeln wie es soll. Wenn da nicht die Daten drin stehen die es sein sollten, dann gibts halt nen Fehler.
-
Cosmic@Code schrieb:
Die Dateiendungen sind doch nur für den User da. Jedem Programm sollte doch egal sein, wie das File heißt. Es muss doch nur die Daten die drin stehen so behandeln wie es soll. Wenn da nicht die Daten drin stehen die es sein sollten, dann gibts halt nen Fehler.
Du sagst es: SOLLTE.
Dummerweise scheinen eienige (Windows-)Programme dieses STatement nicht zu kennen!MfG Branleb
-
ProgChild schrieb:
Simon2 schrieb:
Hmmm, sowas würde aber den Einsatz einer Fremd-Std-Lib extrem mühsam machen...
Äh und? Wenn die Std-Lib mit im Compiler integriert wäre, wäre das sogar unmöglich. Die Standard-Lib ist desshalb im Standard, damit man sie nicht wechseln muss.
... warum empfehlen hier denn so Viele, mal eine andere StdLib auszuprobieren, wenn Probleme auftauchen ?
Ich verstehe nicht, warum Du auf meinen Hinweis auf fehlende Kompatibilität mit so viel Emotion begegnest.
Kann sein, dass einen dieses Fehlen nicht stört ... kann aber auch sein, dass man sich diese Option nicht nehmen lassen möchte und deswegen nicht auf ein Entwicklungsumgebung setzt, die einem da (zusätzliche) Steine in den Weg legt.
Wird natürlich nie das einzige Argument für/gegen einen Compiler sein, sondern nur eines unter Vielen ... aber mehr habe ich auch nie behauptet.Gruß,
Simon2.
-
Das einzige doofe an Dateiendungen (vom 8.3 System mal abgesehen) sind die dämlichen Filter bei einigen Programmen wenn man Dateien auswählen will. Unter Linux wo keine nötig aber üblich sind haben die meisten Programme keine Filter, was die Auswahl mühselig macht. Unter Windows haben fast alle Programme solche Dateiendungsfilter was zu Problemen führen kann, wenn man mal unübliche Endungen hat. Bei einigen IDEs zum Beispiel mit .cc .cpp etc.
Selbst Emacs erkennt Dateien nur an der Endung. Zumindest tut es sich schwer .h-Dateien als C++-Header zu erkennen.
Finde die schon deswegen praktisch (Endungen an sich) da sich damit leichter Dateien suchen lassen, ohne immer die Endung in den Namen zu integrieren. Außerdem hat man so mehrere Dateien mit dem gleichen Namen. x.cc, x.h, x.o und x. Ist doch praktisch.
Hm, war ja eigentlich gar nicht das Thema... Egal, bin krank, arbeite mal weiter. Narf.
-
Simon2 schrieb:
... warum empfehlen hier denn so Viele, mal eine andere StdLib auszuprobieren, wenn Probleme auftauchen ?
Ich verstehe nicht, warum Du auf meinen Hinweis auf fehlende Kompatibilität mit so viel Emotion begegnest.
Kann sein, dass einen dieses Fehlen nicht stört ... kann aber auch sein, dass man sich diese Option nicht nehmen lassen möchte und deswegen nicht auf ein Entwicklungsumgebung setzt, die einem da (zusätzliche) Steine in den Weg legt.
Wird natürlich nie das einzige Argument für/gegen einen Compiler sein, sondern nur eines unter Vielen ... aber mehr habe ich auch nie behauptet.Darauf wollte ich garnicht hinaus. Natürlich ist es schön, dass man die Standard-Bib wechseln kann. Und ich halte es auch für einen sehr großen Vorteil, dass die C++ Standard-Bib selbst in C++ geschrieben ist. Bei anderen Sprachen ist das ja nicht unbedingt so.
Was ich sagen wollte war, dass der C++-Standard es ermöglicht, dass man einen standardkonformen C++-Compiler schreiben kann, der auf einem System läuft, das nichtmal ein Dateisystem hat. Ich wollte dich darauf hinweisen, dass das Standardisierung-Komitee sich wohl dafür entschieden hat, nicht als voraussetzung auch noch ein Dateisystem hinzuzunehmen und dafür das auswechseln der Standard-Bib nicht in den Standard aufgenommen hat. Wahrscheinlich, weil man sonst noch in gewissem Maße ein Dateisystem hätte standardisieren müssen.
-
merker schrieb:
In C++ ist nicht definiert, daß ein Header unbedingt eine Datei sein muß.
"iostream" z.B. ist nicht der Name einer Datei sondern nur ein Bezeichner für irgendein abstraktes Gebilde.
Dann hätten "die Leutz" aber auch einen eigenen include-Mechanismus einführen sollen, statt #include weiter zu verwenden.
#include heißt doch "füge den Inhalt dieser Datei an dieser Stelle ein". Wenn C++ nun sagt, dass das aber nicht unbedingt eine Datei sein muss, dann wirds inkonsistent und unübersichtlich.
-
ProgChild schrieb:
...
Was ich sagen wollte war, dass der C++-Standard es ermöglicht, dass man einen standardkonformen C++-Compiler schreiben kann, der auf einem System läuft, das nichtmal ein Dateisystem hat...Aber dann verstehe ich Deinen Einwand noch weniger:
ProgChild schrieb:
Simon2 schrieb:
Hmmm, sowas würde aber den Einsatz einer Fremd-Std-Lib extrem mühsam machen...
Äh und? Wenn die Std-Lib mit im Compiler integriert wäre, wäre das sogar unmöglich. Die Standard-Lib ist desshalb im Standard, damit man sie nicht wechseln muss.
Ich hatte ja lediuglich gesagt:
- WENN wir uns in einem Umfeld bewegen, in dem das über Dateien geregelt wird
- UND sich ein Compilerhersteller dafür entscheidet, diese Dateien nicht "iostream", sondern "iostream.hppxyz" zu nennen,
- DANN würde diese Entscheidung einen StdLib-Wechsel unnötig erschweren.... und ich würde das als Nachteil (dieses Compilers) empfinden.
Gruß,
Simon2.
-
Simon2 schrieb:
Ich hatte ja lediuglich gesagt:
- WENN wir uns in einem Umfeld bewegen, in dem das über Dateien geregelt wird
- UND sich ein Compilerhersteller dafür entscheidet, diese Dateien nicht "iostream", sondern "iostream.hppxyz" zu nennen,
- DANN würde diese Entscheidung einen StdLib-Wechsel unnötig erschweren.... und ich würde das als Nachteil (dieses Compilers) empfinden.
Lassen wir das mal so stehen. Ich hatte lediglich gesagt, dass der Standard das erlaubt, die Header in anderen Dateien unter zu bringen, wenn man es will und der Standard nicht vorsieht, dass ein Compiler den wechsel der Standard-Bib ermöglichen muss. Ob das jetzt klug ist oder nicht, darüber kann man ja streiten, aber darum ging es ja garnicht.
-
dm schrieb:
Dann hätten "die Leutz" aber auch einen eigenen include-Mechanismus einführen sollen, statt #include weiter zu verwenden.
Dieser eigene Mechanismus heißt #include <...>. Zum Dateien einbinden gibt es #include "...".
-
ProgChild schrieb:
...Ich hatte lediglich gesagt, ...
Es wäre vllt. etwas einfacher gewesen, wenn Du wirklich einfach "lediglich gesagt" hättest.
Gruß,
Simon2.
-
Simon2 schrieb:
Es wäre vllt. etwas einfacher gewesen, wenn Du wirklich einfach "lediglich gesagt" hättest.
Warum einfach, wenns auch kompiziert geht.
