Interessante Defintion, habe ich noch nie gehört? Konnte ich gerade auch im Internet nicht wirklich finden. Für mich und im Internet sind das immer schon Quelldateien bzw. Sourcefiles gewesen.
Unter Module verstehe ich das: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1778.pdf, http://clang.llvm.org/docs/Modules.html


Meiner Meinung nach hast du leicht falsch bzw. nicht aktuelle Vorstellungen.
Um mal ein konkretes Gegenbeispiel zu nennen: D
Eine Sprache mit Templatemechanismen mit viel statischen Codemechanismen die vielfältiger und durchdachter sind als in C++ und das ohne Header/Source Trennung. Die Trennung zwischen Header und Quellcode sehe ich ganz klar historisch. Das Argument das du bereits genannt hast und die simple Implementierung haben es in C eingeführt. C++ hat es übernommen und bisher noch nicht geschafft über diese Altlast hinwegzukommen. Neben der Fehleranfälligkeit(Includeguards, Präprozessor allgemein schlecht debugbar), der Redundanz(Die gleiche Deklaration muss zwei mal identisch dastehen) und Uneleganz(Inkonsistent zum Beispiel bei Templates, oder umständlich bei Konstanten, oder Forwarddeklerationen) ist der gravierendste Nachteil den du, wie ich nicht ganz nachvollziehen kann, bereits in einem anderen Kontext verwendet hast:

Das Problem am Headersystem ist ein "Lawinenproblem". Jeder Header inkludiert Weitere. Dadurch das es sich letztendlich bloß um ein Zusammenfügen seitens des Präprozessors handelt, müssen eine immense Menge Header für jede Datei zusammengebaut werden. Dabei entstehen nicht selten MB große temporäre Dateien die auch noch geparst werden müssen. Und das immer und immer wieder, einmal für jede Compile Unit, anstatt die Aufgaben sauber zu teilen und jede Datei nur einmal zu verarbeiten.

Was meinst du damit?

Kannst du Beispiele nennen?

Point taken. Das ist gewissermaßen ein Problem, was man aber mit Arbeitsspeicher erschlagen kann.

Wäre mir neu, dass irgendein Compiler diese Zwischenprodukte auf die Festplatte schreibt.


Das Problem, das du aber glaube ich noch nicht verstanden hast, ist, dass man bei Templates (Templates! nicht Generics!) eben nicht nur Interface im Header stehen hat, sondern auch Implementation. Und das geht auch garnicht anders, da die Implementation noch nicht fest steht, bis das Template instanziiert wird. Man kann nicht einfach Löcher lassen wo templateabhängige Werte sind und die Arbeit dem Linker überlassen. Da braucht es mehr Logik und Wissen, als der Linker noch hat (z.B. könnten Funktionen benötigt werden, die weggeschmissen wurden (weil nicht gebraucht), weshalb der Linker keinen Zugriff auf diese hat).

Und in dem Moment wäre eine Trennung wieder ad absurdum geführt.

grüße,
Horazont

p.s.: Das C++-Templatesystem ist Turing Complete. Vielseitiger gehts nich *scnr*

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Ich meine damit schlicht und ergreifend das das bei "normalen Funktionen" die gleichen Informationen die im Header stehen sich auch schon in der Quelldatei stecken. Die Information in der Deklaration einer Funktion ist redundant. Das das nicht so praktisch ist, als wenn das nicht notwendig wäre, sollte leicht ersichtlich sein. Mehr Schreibaufwand. Dateien müssen Gewechselt werden. Änderungen an der Deklaration müssen doppelt gemacht werden.


Na, die Beispiele waren doch in der Klammer.
Eine Template-Funktion muss anders als alle anderen Funktionen mit in den Header. Konstanten sind besonders umständlich zu definieren. Insbesondere bei Templatekonstanten wird es richtig wild. Während man Templatefunktionen einfach in den Header packt, geht das da wieder nicht so. Da braucht man 2 weitere sinnlose Zeilen um zu definieren. Forwarddeklaration funktioniert wieder anders und erhöht wieder die Redundanz. Der C++14 Standard hat mit "constexpr"-Konstanten hier einen guten Schritt gemacht. Bloß, wann werde ich das in Visual Studio haben? Mit etwas Glück noch in diesen Jahrzehnt. Toll.


Ja das kann man. Allerdings ist "erschlagen" zu recht negativ behaftet. Das Hauptproblem ist die verbratene CPU Zeit und die dafür kreiselnde Festplatte(Außer es ist noch gecached). Es müssen leicht hunderte Dateien dafür geöffnet werden. Dann muss der Präprozessor sein Bestes versuchen und das alles zusammen basteln. Und noch CPU intensiver ist dann das parsen des Codes. Präprozessor Ausgabecode ist schön und nett, aber damit kann weder Syntaxprüfung, Optimierung oder Codegenerierung damit arbeiten. Die MB weise Code müssen vom Compiler erstmal "verstanden" werden und in einen internen einfacheren Zustand überführt werden (AST). Und der Syntax muss auch überprüft sein. Und damit gibt sich der Compiler ab. MBs werden so für jede Datei verarbeitet obwohl jede einzelne Datei nur einige KB groß sein kann. Die Arbeit den Code in den inkludierten Headern zu verstehen wird also für jede Compile Unit wiederholt anstatt sich diese Arbeit zu teilen und jede Datei nur einmal einzulesen.


Na, so habe ich das auch nicht gemeint. Die temporäre Datei war nur bildlich gemeint, halt als Präprozessorausgabe. Das diese Daten nicht vorher auf die Festplatte geschrieben werden, hoffe ich stark.

Das Problem lässt sich ganz einfach lösen in dem man zum Beispiel das generieren von Maschinencode zu einer "Linker"aufgabe erklärt. In der Praxis wird das für LTCG ohnehin schon teilweise so gemacht. Vielleicht überraschend ist, dass dies nicht das nicht so kritisch in der Performance wie man vielleicht annehmen könnte wenn diese Arbeit immer wieder gemacht wird. Das kann man in der Praxis deutlich erkennen, das insbesonderei n C++ andere Abschnitte dominieren. Um außerdem nochmal zu den Templates zurück zu kommen. Wenn die Templates nicht erst im "Linker" instanziert werden sondern vom Compiler wird auch diese Arbeit doppelt gemacht und teilweise wieder verworfen werden.

PS: Als Beispiel in D nenne ich zum Beispiel mal Compile Time fähige Strings, "Static If" oder auch Mixins. In C++ geht das so gut wie nicht.

Da habe ich mir gestern den Kopf zerbrochen, ich habe anstelle endl end geschrieben.
Anstelle einer kurzen Fehlermeldung, kommt ein riessen Block mit Meldungen, die mir wenig sagten.

Ich habe mit Code::Block kompiliert.
Bei Eclipse sieht man den Fehler sofort.

_________________
OpenGL

Gehtso. Wenn man drauf steht kann man ca. die hälfte der Informationen weglassen (Argumentnamen sind im Header nicht erforderlich). Aber das gehört in die gleiche Kategorie wie das was ich neulich schon sagte: Das dokumentiert den Code, man hat das Interface an einer Stelle vollständig zusammengefasst.

Ich meinte Beispiele in Form von Code, denn meine Vermutung ist, dass du von einigen Dingen eine falsche Vorstellung hast. Früher waren Konstanten tatsächlich anstrengend, mit C++11 darf man static const, static constexpr und normale Member in der Klassendeklaration initialisieren.

Was dein Problem mit Forward declarations ist, versteh ich nicht. Die sind genauso wie in Pascal class Foo;. constexpr haben wir schon in C++11. Visual Studio kannste gleich vergessen – meine favorisierte Verschwörungstheorie dazu ist, dass Microsoft die leute zu C# drücken will, indem es einfach keine neuen C++-Features implementiert. Dass VS nen scheißcompiler ist, ist klar. Aber da hilft dir D auch nicht.


Jau klar. Das greife ich nicht weiter an. Das ist ein Problem, das ist aber inhärent in der C/C++ Architektur. Das kann man zu teilen beheben indem man Precompiled Header einführt, aber halt nicht ganz. Ich würde fast vermuten, dass man das auch aus gründen der C-Kompatibilität nicht weggeben will. Es ist schließlich ein Feature von C++, dass man mit einem extern "C" {}-Block ein C-kompatibles ABI erhält.


Damit verschiebt man das Problem nur in den Linker. Man braucht trotzdem die Informationen aus allen Headern, die irgendwo inkludiert wurden. Der Linker ist allerdings heute schon bei vielen großen Projekten ein echtes Problem, was die Memory Use betrifft. Meist kommt die Peak Memory Usage beim Linken zu stande (siehe z.B. Firefox oder Chrome, welche man auf einem 32-bit Windows-System nicht mehr bauen kann, weil der Linker mehr als 2 GB RAM⁽¹⁾ braucht).

StaticIf: Kann man problemlos mit einem Template implementieren:

Das zwingt den Compiler noch nicht dazu, das zur Compile Time zu evaluieren, aber er wird es tun, sobald optimierungen angeschaltet sind, bzw. es erforderlich ist (z.B. weil es als Templateargument verwendet wird). Will man die Evaluation erzwingen, ist es trivial ein Wrappertemplate zu schreiben. Man kanns sicher auch anders implementieren, sodass immer zur Compile Time evaluiert wird, aber das war die lösung off the top of my head.

Bei Compile-Time fähigen Strings kann ich nur sagen Point taken. Man kanns zwar mit der Templatesprache implementieren (sie ist Turing-Complete, after all), aber das wäre frickelig und kaum usable.


1: Windows reserviert die Hälfte des 32-bit Adressraums für sich, daher bekommt man auf 32-bit nur 2 GB pro Anwendung. Irgendwie sowas war da. Vielleicht brauchen die auch inzwischen 4 GB RAM.

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Dafür hat meine IDE Codefaltung.


Das Problem was ich damit habe ist, das es inkonsistent ist. Es gibt zwei eigentlich widersprüchliche Weisen sich Zugriff zu Funktionen/Klassen zu verschaffen. Außerdem ist mein Problem mit Forward-Deklaration das die Dinge damit nicht definiert sind und damit der Zugriff nur sehr eingeschränkt möglich ist. Zwei Templateklassen die aufeinander zugreifen sind damit grundsätzlich nicht möglich. Nested Classes lassen sich auch nicht Forward deklarieren. Außerdem nervt es mich das ich immer nach möglicher Forward-Deklaration ausschau halten muss um die Includeketten zu durchbrechen. Und manchmal habe ich mich sogar schon dazu durchgerungen, deshalb eine zusätzliche Indirektion(Pointer) einzubauen nur damit der Header nur in der Quelldatei inkludiert werden muss.


Jaein. Verabschiede dich für den Gedanken mal gedanklich von den Headern. Das ist eine Eigenheit aus der Historie von C++. Das Problem entsteht nicht dadurch das alle Dateien benötigt werden(Das ist automatisch so) sondern das alle Dateien für jede einzelne Datei verarbeitet werden müssen. Bein n Dateien die jeweils m Header inkludieren ist es ein O(n*m) Problem, weil jede Datei jede ihre eingebundenen Header auswerten muss. Wenn alle Dateien nur einmal ausgewertet werden ist es ein O(n+m) Problem. Der Linker wertet alle Dateien aus und wendet sie dann auf alle anderen an, ohne das irgendeine Datei mehrmals ausgelesen wurde.


Das kann sein. Nichtsdestotrotz würde man auch wieder Speicher sparen weil keine Templates mehrfach für den selben Typ ausgewertet würden oder komplexes Namemangeling vorher statt findet. Der Speicherverbrauch würde vielleicht leicht steigen, ich sehe jedoch keinen Grund für einen wirklich drastischen Anstieg. Wie gesagt, wie eh bereits teilweise vollkommen im Linker kompiliert. Beim LLVM/Clang zum Beispiel besonders offensichtlich. Dort schickt man den IL-Code direkt in den Linker für LTCG. Und er ist für seine schnelle Kompiliergeschwindigkeit und geringen Speicherverbrauch bekannt. Die aller meiste Zeit geht einfach für das Einlesen, Parsen und so weiter drauf. Das ist nicht abzustreiten und das daher mehrfach zu machen ist daher ineffizient und ein anderes System effizienter wäre.


Ähm, ne nicht ganz. Das wäre eher ein "static choose". Etwas Ähnliches wie static_if geht zwar teilweise auch in C++, aber nicht immer und weniger praktisch. Wenn dann sollte man das mit Template-Spezialisierung oder "std::enable_if" machen. "static_if" kannst du beliebige Codeteile verzweigen. Variablen erstellen oder nicht. Klassen oder nicht. Auch wenn der nicht angewendete Zweig der Verzweigung einen Compilerfehler auslösen würde, es spielt keine Rolle.

was gibt es denn für Fehlermeldungen?
Endl steht für end-of-line und ist einfach nur dein "\n". End hingegen ist eine Funktion.

@Header

Ihr solltet nicht immer so kompliziert denken
Die Problematik ist einfach der Tatsache geschuldet, dass ,genau wie bei zum Beispiel Pascal, alle Symbole vor der Verwendung deklariert werden müssen. in C gibt es hier nur die spezielle Ausnahme das undeklarierte Funktionen und unvollständige Typen verwendet werden dürfen.
Gäbe es zum Beispiel keine vorgezogenen Deklarationen müsste man mehrere Durchläufe machen um die gegenseitige Rekursion hinzubekommen. Das es hier Nachteile gibt ist klar, dafür haben aber Sprachen wie Java und co. ganz andere Nachteile, wie zum Beispiel die von OpenglerF angesprochene Performance.

Das ist übrigens einer der Gründe für Header und Include, und nicht die Auslieferung von binären Modulen. Fragt euch einfach mal warum eine ganze Reihe von älteren interpretierten Sprachen auch auf solche Systeme setzen.

_________________
Meine Homepage

Es war ein Tipp-Fehler, das gemeine, end und endl habe die gleiche Syntaxvorhebung.

Die Fehlermeldung:

_________________
OpenGL

Der sehr kleine aber feine Unterschied zwischen "std::endl" und "\n" ist, dass Zweiteres nur ein Zeilenumbruch ist und Ersteres ein Zeilenumbruch und einen augenblicklichen Flush des Ausgabestreams auslöst. Ich würde in praktisch allen Fällen einfach "\n" verwenden, ist schneller und kompakter.

Diese beiden Zeilen machen das Gleiche.


Unten Pascal geht \n nicht. Anscheinend wird '\n' direkt vom C-Compiler abgefangen.

_________________
OpenGL

ja, Pascal unterstützt, soweit ich weiß, keine Escape Sequenzen. Das ist allerdings soweit verbreitet das hier Pascal eher der Sonderling ist

_________________
Meine Homepage

Ich hatte diese nie vermisst, auch als ich noch unter DOS programmierte.

Da einzige was mir unter Escape-Sequenzen bekanntwar, waren die Funktionen in ANSI.SYS.

_________________
OpenGL

\n ist nicht das gleiche wie #13#10, sondern nur #10.

grüße

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Stimmt #10 reicht für die Windows-Konsole, aber notepad.exe hat Probleme, wen #13 fehlt, obwohl beides von m$ kommt.

Interessanterweisse machen alle 4 Zeilen das Gleiche.

Unter Linux macht die 3. Zeile eine Leerzeile in der Mesagebox.

_________________
OpenGL

Sicher das endl immer das gleiche ist wie #13#10? Ich dachte immer auf Linux Systemen macht das ein #13 und auf Windows Systemen ein #13#10. Halt jenachdem was fur das System ein gültiger Zeilenumbruch ist...

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.