Generell sind aber die Dateiendungen dem Compiler völlig egal...

...Jedem C++-Compiler-Hersteller ist es freigestellt, dass er beim Laden, der iostream, z.B. in wirklichkeit die Datei iostream.hpp lädt.

Hmmm, sowas würde aber den Einsatz einer Fremd-Std-Lib extrem mühsam machen...

Gruß,

Simon2.

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.

Es gibt Systeme, die brauchern keine Datei-Endungen, um Datei-Typen auseinander zu halten. Warum sollte C++ sowas aufzwingen.

Diese Systeme würden aber einen C++ Header bestenfalls als Textfile identifizieren können. Aber klar, den Präprozzi interessiert es nicht die Bohne, was im #include <> drinsteht.

ProgChild schrieb:

Es gibt Systeme, die brauchern keine Datei-Endungen, um Datei-Typen auseinander zu halten. Warum sollte C++ sowas aufzwingen.

Diese Systeme würden aber einen C++ Header bestenfalls als Textfile identifizieren können. Aber klar, den Präprozzi interessiert es nicht die Bohne, was im #include <> drinsteht.

Mein Gnome gibt mir als Datei Typ "C Header" aus.
bzw bei Sourcen "C Quelltext"

und file gibt das aus:

$ file iostream 
iostream: ASCII C++ program text

MfG Branleb

ProgChild schrieb:

Es gibt Systeme, die brauchern keine Datei-Endungen, um Datei-Typen auseinander zu halten. Warum sollte C++ sowas aufzwingen.

Diese Systeme würden aber einen C++ Header bestenfalls als Textfile identifizieren können. Aber klar, den Präprozzi interessiert es nicht die Bohne, was im #include <> drinsteht.

Mac OS speichert zu jedem File immer ein Resourcen File. Mac OS 9 hatte zB keine Dateiendungen - es gab das Konzept einfach nicht.

Mac OS speichert zu jedem File immer ein Resourcen File. Mac OS 9 hatte zB keine Dateiendungen - es gab das Konzept einfach nicht.

Und dieses Ressourcen File nervt auf USB Sticks usw ...
v.a. wenn man keine Dateiendungen hat und die Datei unter WIndows lesen will - dann muss man wissen was es ist ...
Und dann immer noch eine kleines dummes adnres file, was unnöig erscheint ...

Wieso kamen die Leutz auf die Idee bei den C++ Standardheader keine Endung zu nehmen

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.

Es hängt vom Präprozessor und vom Kompiler ab, wie aus "iostream" an Informationen gelangt wird.

Dateien haben sich dabei aber als sehr praktisch erwiesen.

Die verwendung der Headerdateien mit der Endung .h wie zum beispiel iostream.h
funktionieren nur noch aus gründen der kompatiblität für ältere Programme.

Als nun die neudefinierte Version der Standardbibliothek mit vielen neuen Hilfsmitteln hinzugefügt wurde, war der Name der Headerdateien ein Problem.
Hätte man hierbei wieder einen Namen wie iostream.h verwendet, so würde man Probleme mit älteren Programmen bekommen. Daher hat man kurzerhand beschlossen, das .h aus den Standard-Headerdateien zu entfernen.

Das ganze bezieht sich auf das problem das Namespaces erst 1997 eingeführt wurden, und das heute entweder std::cout geschrieben werden muss oder eben mit using namespace eingefügt werden muss.

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

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.

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.

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

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.

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

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.

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

...Ich hatte lediglich gesagt, ...

Es wäre vllt. etwas einfacher gewesen, wenn Du wirklich einfach "lediglich gesagt" hättest.

Gruß,

Simon2.

Es wäre vllt. etwas einfacher gewesen, wenn Du wirklich einfach "lediglich gesagt" hättest.

Warum einfach, wenns auch kompiziert geht.