Haben Headerdateien eigentlich Vorteile?

Header-Dateien sind aus der Mode, genauso wie du.

Gehts noch?

kartoffelsack

du glaubst ja sogar wirklich das man fuers taegliche arbeiten compilerfarmen braucht, und das kernel compilieren tage dauert. 
und das einem das tag fuer tag die zeit stiehlt.

Ich brauch für die tägliche Arbeit keine Compilerfarm, aber mittelgroße Projekt ( 50 bis 150 Klassen) braucht mit den mir (aus mittelgroßen Projekten) bekannten Compilern (VC++ 6 bis 8, Borland C++Builder) locker mal 5 bis 15 Minuten zum compilieren (wenn man alles neu übersetzt). Ohne Vorcompilierte Header. Wenn man selbige in den Griff kriegt, bringt man die Zeit meist auf unter 2 Minuten. Und sorry, ich kenn kein Java oder auch Delphi-Projekt derselben Größenordnung (und ich kenne einige), deren Compilezeit über ner Minute liegt.

Wann tut man schon mal was komplett neu übersetzen?

Artchi

Also ich hab damals an einem Dreamcast-Spiel gearbeitet und da hat das kompilieren unter VC++6 auf einem 500 MHz PIII geschlagene 20 Minuten gedauert. Manchmal war halt ein Rebuild nötig... den genauen Grund weiß ich nicht mehr, kam aber gut einmal am Tag (vielleicht alle zwei Tage) vor. 20 Min. waren nicht lustig.

Meine Java Projekte brauchen definitiv nicht so lange..

daHa

wie schon gesagt, neue ansaetzte bringen, hoffentlich, neue bessere loesungen.
hab ihc ja shcon geschrieben.

auch das, mMn, compilerzeiten in der regel nicht derartig relevant sind das sie bei einer technologieentscheidung eine rolle spielen.

da sind zur verfuegung stehende ides und uml tools eher ein argument(plattform unabhaenig, so wie zb fuer java exestierend), als halbseidenen tehcnische begrunedungen.

wie oft pro tag kompilierst du alles?

ich verwend keine vorkompilierten header, make kuemmert sich aber darum immer nur die von aenderungen betroffenen teile neuzukompilieren, die wartezeiten bis ich das aktuelle build hab sind in der regel vernachlaessigbar.
make clean & make wird sicherheitshalber hin und wieder vor pausen mal ausgefuehrt, zeitverlusst also ca. 0.
die momente wo man zur caffee pause gezwungen wird sind also eher nicht (mehr) die regel.

ich finde kuenstliche argumente wie zb
include reihenfolge probleme
oder es so hinstellen das man tag taeglich wegen builds stunden an zeit verliert
nunja, eher nicht so gut.

auch die zwingende logik
c/c++ lange compilezeiten -> schlecht
java/c# kuerzere compilzeiten -> also besser
is fuer sich allein eher nixsagend, weil
scriptsprache XY am besten weil gar kein compilezeiten(??haehh) ( und was war mit VB, seiner zeit vorraus weil keine header) waer die marketingtechnisch brauchbare weiterfuehrung an der man sich dann argumentativ sinnlos aufhaengen kann, und das bringts nicht.

die sichtweise - es gibt jetzt was neuere also ist alles aeltere scheisse - kann ich auch nicht unbedingt nachvollziehen, vorallem und schon gar nicht wenn nicht praxisrelevante beispiele kommen.

und schon gar nicht nachvollziehen kann ich wenn sachen fuer scheisse erklaehrt werden fuer die es anscheinend keine brauchbaren alternativen gibt.

und fuer viele berreiche fehlen noch loesungen die in java/c#(ok is neuer, schaum ma was kommt) exestieren.
warum ist das so? doch nicht fuer alles brauchbar und alles alte unbrauchbar bis scheisse oder weil alle welt bloed ist und die herrlichkeit und ueberlegenheit von java/sonstigen nicht an und erkennt?

aber ich glaub ich wiederhohl mich jetzt, das sollt schon in vorigen posts zu finden sein.

GPC

Nicht alles was alt ist, ist schlecht, aber neues ist u.U. besser. Die neuen Übersetzungsmodelle sind einfach besser.

Das Argument "Ich kann mir die Schnittstelle anschauen mit Headern" zieht bei mir nicht, ich erwarte ein "docs"-Verzeichnis mit einer anständigen Dokumentation, z.B. JavaDoc oder Doxygen.

Und wenn ich, um die Implementierung zu verbergen, jedesmal nen Proxy schreiben müsste, ja dankeschön, ich hab ja auch nichts besseres zu tun.

Ich persönlich sehe keinen wirklichen Vorteil der Header, ich habe mich zwar an die Benutzung gewöhnt, aber mögen tue ich sie deshalb nicht übertrieben.

Optimizer hat noch viel mehr gute Argumente gebracht, die sich _nicht_ auf "alt->scheiße, neu->geil" gestützt haben. Warum wehrst du dich so dagegen, dass es auf dem Gebiet inzwischen einfach bessere Lösungen als das Header-Konzept gibt? Es kommt ja auch keiner mehr, und versucht uns das Beta-Format anzudrehen, weil DVD so scheiße ist.
Wenn du gegen Vogelgrippe genauso immun bist, wie gegen die Argumentation von Optimizer, hast du nichts zu befürchten...

MfG

GPC

kartoffelsack

wie oft pro tag kompilierst du alles?

Mehrmals. Sorry, aber entweder ich (und wir hier in unserer Firma) arbeiten alle völlig anders als der Rest der Welt oder???

Bei VC++ bis zur aktuellen Version gibts beim Compilieren manchmal Fehler, die keine sind und sich durch einen rebuild beheben lassen. Beim BCB musste, wenn Du z.B. ne DLL debuggst relativ häufig alles neu übersetzen, weil er sonst probleme mit den Debug-Symbolen hat.

Wenn ich zwischen Debug- und Release-Version hin und herschalte, compilier ich grundsätzlich alles neu (bei BCB muss man das z.B. weil er die obj-Dateien nicht automatisch so schön trenn wie VC++ - man kanns einrichten, aber das ist nicht die Standardeinstellung).
Jedesmal wenn ich zwischen Unit-Tests und dem Programm umschalte, jedesmal wenn ich die aktuellste Version auf einen Testrechner kopiere etc. übersetze ich neu.

Außerdem ändert sich auch ab und zu ein Header, der zwar nicht das Neucompilieren des gesamten Projekts, aber zumindest eines Großteils bewirkt. Und das hat noch nicht mal was mit ner Schnittstellenänderung zu tun, sondern vielleicht nur weil ich ne private Variable umbenenne.

Tut mir leid, wer in einem agilen Prozess Software Entwickelt übersetzt sein (mittelgroßes) Programm oder seinen Komponente mehrmals täglich neu.

ich verwend keine vorkompilierten header, make kuemmert sich aber darum immer nur die von aenderungen betroffenen teile neuzukompilieren, die wartezeiten bis ich das aktuelle build hab sind in der regel vernachlaessigbar.

Wenn Du 4 x am Tag alles neu compilierst und es 10 Minuten dauert sind 40 Minuten um. Das finde ich eigentlich nicht vernachlässigbar. Erst recht nicht, wenn der Kunde nen unangenehmen Fehler hat, Du selbigen auch schnell findest und behebst, aber trotzdem den ganze QS-Prozess durchlaufen möchtest: Unit-Test, Release-Version erzeugen, Installation auf Testsystem, Anwendertest, ausliefern zum Kunden. Da kann die Übersetzungszeit schon mal die hälfte Deiner Reaktionszeit ausmachen.

oder es so hinstellen das man tag taeglich wegen builds stunden an zeit verliert
nunja, eher nicht so gut.

Bei mir schätzung pro Tag: eine gute Stunde. Wär Dir sehr verbunden, wenn Du mir sagen würdest, was ich falsch mache.

c/c++ lange compilezeiten -> schlecht

falsch. Hat keiner gesagt. Aber header -> lange compilezeiten -> schlecht. C++ ist gut. Es wäre aber noch viel besser, wenn es ein anständiges Modulsystem hätte.

Artchi

Die wenigsten hier im Thread sagen das C++ schlecht ist. Jeder der mich hier kennt, weiß das ich C++ in allen Belangen z.B. ggü. Java verteidige (ich verdiene meine Brötche mit Java!). Und wenn ICH zugebe, das Header stören und ich das in Java besser gelöst finde, dann soll das was heißen!

Es geht hier nur um die Produktivität des kompilierens, was wiederum sowohl das Build als auch das pflegen (redundanz) angeht. Die Sprache selbst, finden hier wohl die meisten super... sonst wären sie auch nicht hier im C++ Forum.

daHa

4 mal am tag alles neu zu kompilieren erscheint mir heftig.
1 stunde pro tag zeitverlust erscheint mir ebenfalls heftig.
aber das is natuerlich ein argument fuer eine technologie entscheidung.

aber warum, aenderts ihr taeglich eure header?
ist das ein VC++ problem und/oder ein projektstruckturproblem?
gibts leute die mit gcc und make arbeiten und die selben probleme haben?

wieviel zeit wuerdest du mit java sparen, und is das dann tatsaechlich nur reine compilezeit oder liegt das auch daran das du dann nicht immer alles neu uebersetztn muesstest.

kann man da irgendiwe einen mittelwert feststellen um wieviel java /c# schneller waeren beim build? faktor X?
mich wuerds tatsaechlich interessieren.

ich weis, viele fragen, einiges versuch ich eh zum ergoogeln, aber mittlerweile gibts derartig viele dubiose erklaehrungen das mir forumsfeedback vernuenftiger erscheint bzw als ergaenzung sehr willkommen ist.
haengt damit zusammen das projektteile auf mich zukommen wo ich die chance haett neue technologien zu verwenden, und da beschaeftigen mich halt solche fragen.

bei deraritgen compilezeiten koennte man darueber nachdenken das projekt zu untereilen.
meherer statische libs, thematisch/logisch paketmaessig getrennt, fuer jede (kobination) gibts dann extra testprogramm(e), schmale deffinierte schnittstellen, = header, die nicht taeglich geaendert werden und das prob sollt entschaerft sein.

ok, das is jetzt nur so schnell dahingeworfen, aber ich mach das so.
event haben andere leute andere loesungen bzw is die loesung nicht immer praktikabel bzw nur fuer die art projekte tauglich mit denen ich beschaeftig bin, ich weis ich bin a bissl zulang spezialisiert/limitiert auf einen bereich.

selten das probleme gleichzeitig in mehreren packeten gleichzeitig vorkommen/betreffen bzw derartig massiv sind das totale rebuilds benoetigt werden.
mit der packetunterteilung in statische libs haelt sich die veroegerung wenn schnell reagiert werden muss in grenzen
und ausserdem kann ich gegen diverse versionen tauschen in dem ich einzelne der libs beim linken austausch, kann auch ganz angenehm sein.

kartoffelsack

aber warum, aenderts ihr taeglich eure header?
ist das ein VC++ problem und/oder ein projektstruckturproblem?
gibts leute die mit gcc und make arbeiten und die selben probleme haben?

Die Projekte von denen ich rede haben einen Umfang, dass sie in etwa noch ein Entwickler alleine beherrschen kann. D.h. es sind keine Riesendinger, aber ein Entwickler sitzt schon ein paar Mannmonate dran. Und wenn man halt so lustig vor sich hinentwickelt, dann ändert man auch mal nen Header. Private Members und Funktionen kommen dauernd dazu, selbst wenn die Schnittstelle stabil bleibt. Und dann kommts halt drauf an, wie viel neu übersetzt werden muss.

bei deraritgen compilezeiten koennte man darueber nachdenken das projekt zu untereilen.
meherer statische libs, thematisch/logisch paketmaessig getrennt, fuer jede (kobination) gibts dann extra testprogramm(e), schmale deffinierte schnittstellen, = header, die nicht taeglich geaendert werden und das prob sollt entschaerft sein.

Prinzipiell kann man die Compilezeit mit pimpl, wirklich sauberen Ableitungshierarchien und Libs natürlich reduzieren. Aber gerade Libs sind halt schon deswegen sehr unangenehm und per se aufwändig, weil Du für die verschiedenen Compilereinstellungen (debug / release) andere Versionen haben musst.
Es mE einfach ein c++Problem, das man in anderen Sprache nicht hat - und aus dem mangelhaften Modulsystem entsteht. Man muss aber natürlich sagen,dass Compilezeiten schon deswegen schon relativ groß sind, weil meist ein paar Bibliotheken mit ein paar schlaueren Template-Sachen verwendet werden. Wenn Du C programmierst oder C++ ohne Templates dann kannst Du viel problemloser alles mal neu übersetzen.

Verschiedene C++-Compiler machen sujektiv kaum nen Unterschied (BCB, VC++, Gnu, wobei ich mit letzterem noch nie was ernsthaftes gemacht hab).

wieviel zeit wuerdest du mit java sparen, und is das dann tatsaechlich nur reine compilezeit oder liegt das auch daran das du dann nicht immer alles neu uebersetztn muesstest. 
kann man da irgendiwe einen mittelwert feststellen um wieviel java /c# schneller waeren beim build? faktor X? 
mich wuerds tatsaechlich interessieren.

Das ist schwer zu sagen. In Eclipse muss man halt praktisch nie compilieren, nur um die Tippfehler rauszukriegen, weil im Hintergrund ständig übersetzt wird und die Fehler unterringelt werden. Wenn ich aber jetzt die Compilezeiten von cpp z.B. mit Delphi vergleiche: Ohne Vorkompilierte Header: locker Faktor 30. Mit vorkompilierten Headern: vielleicht Faktor 10. Beides reine Schätzung aus dem Bauch raus. In Wirklichkeit ist es aber halt dann doch nicht so krass, weil ich in nem Projekt, das schneller compiliert viel öfter auf compilieren drücke. In Delphi/Java ohne Eclipse drückt man halt dauernd auf übersetzen. In C++ kanns schon mal ne halbe Stunde dauern, bis ich mir das wieder antun will. Subjektiver Unterschied Delphi/Java: in etwas gleich.

daHa

entschuldigung, aber diese argument
> 150 Klasssen
und nicht in logische komponenten gepackt, mit deffinierten schnittstellen?
und probleme weil mehrmalts taeglich komplette rebuilds stattfinden?
ich denke da hat jemand sehr viel arbeit vor sich, gut so, das sichert den job.

probleme mit debug/release
eher selten

bei handgeschriebenen makefiles eher ein arbeitsaufwand, aber kein problem.
heutige tools wie anjuta, kdevelop, demnaechst hoffentlich bald eclipse/CDT, macht jetzt schon sehr viel grossartig, erledigen diesen aufwand nebenbei.
und haben noch viele nuetzliche andere funktionen

wesentlich mehr zeitaufwand bei c++ ist (und das ist ein argument), das gegenueber java alle diese tools nicht so gut sind wie die zur verfuegung stehenden java tools.
speziel uml bereich ist ein problem.

TheBigW

Um zumindest mal ein Argument zu entkräften:

Meiner Meinung nach müssten die heutigen IDEs einem auch mehr unter die Arme greifen, um das Arbeiten mit den Headern zu erleichtern. Z.B. kann ich in VC++ 2003 (2005 weiß ich nicht) immer noch nicht zwischen Header und CPP springen. Das kann die Codeblocks-IDE schon, was zeigt, das es nötig ist.

Option Strict Off
Option Explicit Off

Imports EnvDTE
Imports System.Diagnostics

Public Module Opac

    Function WalkProjectItemsAndOpen(ByRef items As ProjectItems, _
                                     ByRef name As String) As Boolean
        Dim item As ProjectItem

        If ReferenceEquals(items, Nothing) Then
            Return False
        End If

        For Each item In items
            If Not item.SubProject Is Nothing Then
                MsgBox(item.SubProject.Name())
                If WalkProjectItemsAndOpen(item.SubProject, name) Then
                    Return True
                End If
            End If
            If Not item.ProjectItems Is Nothing Then
                If WalkProjectItemsAndOpen(item.ProjectItems, name) Then
                    Return True
                End If
            End If
            If item.Name = name Then
                Dim op As ItemOperations
                op = DTE.ItemOperations
                op.OpenFile(item.FileNames(0), Constants.vsViewKindTextView)
                Return True
            End If
        Next
        Return False
    End Function

    Sub Swap_H_CPP()
        Dim proj As Project
        Dim doc As Document
        Dim name As String
        doc = DTE.ActiveDocument
        name = doc.Name

        If name.EndsWith(".h") Then
            name = name.Replace(".h", ".cpp")
        ElseIf name.EndsWith(".cpp") Then
            name = name.Replace(".cpp", ".h")
        End If

        For Each proj In DTE.Solution.Projects
            If WalkProjectItemsAndOpen(proj.ProjectItems, name) Then
                Exit Sub
            End If
        Next

        Beep()

    End Sub

End Module

kommt oroginal von codeproject -> nur a bissel modifiziert um auch projekt unterordner zu durchsuchen und bei mir auf Strg+Alt+Space gelegt - fertig.

ansonsten finde ich Trennung von Design und Implementierung immer noch genial (auch - oder gerade wenn ich im Moment mehr C# mache), weil man sich zwangslüfig mehr Gedanken machen muß.
Sry für eventuell doppelte comments -> hab leider nicht den ganzen post gelesen.

Artchi

Ehm, vielleicht bin ich doof. Aber was ist das was du da gepostet hast? Was hat das mit C++ zu tun? Ist das Pseudocode?

Ein Makro mit dem man Visual C++ erweitern kann.

mantiz

Sieht für mich nach nem Macro aus, welches die cpp-Datei öffnet, wenn die h-Datei geöffnet ist und umgekehrt.
Ist zwar nicht genau das hin-und-her-springen zwischen Deklaration und Implementierung, aber man muss sich ja nur zu helfen wissen.

// Zu spät ...

daHa

VC zweitausendirgendwas ++ hinkt anscheinend hinterher

wies heutzutage in der praxis funktioniert sieht man zB da

http://www.kdevelop.org/doc/technotes/navigation.html

und die ide kann mit mehreren sprachen umgehen.

selbst fuer brauchbare editoren gibts switch header implemantation plugins, in unterschiedlicher qualitaet.

Artchi

VC zweitausendirgendwas ++ hinkt anscheinend hinterher

wies heutzutage in der praxis funktioniert sieht man zB da

http://www.kdevelop.org/doc/technotes/navigation.html

Wenn ich mir das durchlese, kann VC++ das ebenfalls, bis auf Case 7. Das Makro von Codeproject werd ich mal ausprobieren.

und die ide kann mit mehreren sprachen umgehen.

Naja, kann VS auch. So ist es ja nicht.

Aber egal.. es ist jedenfalls traurig, das man mehr Menüpunkte braucht, um durch einen Source zu navigieren. Klar, mein Lösungsvorschlag war, das ich solche Features brauche. Aber auch nur, weil sich das Header-Problem nicht von heute auf morgen streichen lässt. Optimal wäre es, wenn man erst garnicht diesen Leidensdruck hätte, um solche Features haben zu wollen.

kartoffelsack

entschuldigung, aber diese argument
> 150 Klasssen
und nicht in logische komponenten gepackt, mit deffinierten schnittstellen?
und probleme weil mehrmalts taeglich komplette rebuilds stattfinden?
ich denke da hat jemand sehr viel arbeit vor sich, gut so, das sichert den job.

So ein Projekt ist durchaus in logische Komponenten gepackt. Mit Namespaces. Wenn ich jetzt aber eine wirkliche Trennung, die sich auf die Compile-Abhängigkeiten auswirkt, haben will zwischen zwei Teilen haben will, hab ich zwei Möglichkeiten:

Ne abstrakte Basisklasse. D.h. ich bemühe Polymorphie, obwohl ichs garnicht brauch.
Oder pimpl. Und das ist va. Tipparbeit, die einen nicht unerheblichen Wartungsaufwand nach sich zieht. Und das nur deswegen, weil ich in der Klasse, die die Schnittstelle in den anderen Systemteil darstellt, eben nicht sauber zwischen Deklaration und Definition trennen kann, sondern private Elemente über die Header als zur Schnittstelle gehörig definiert werden.

Genau das Problem hab ich in Java nicht. Da bilde ich einfach meine Packages und fertig.

kartoffelsack

Nachtrag:
Bin grad zufällig auf ein boost-Proposal gestoßen, dass sich dem Problem der Abhängigkeiten, Compilezeit etc. annimmt, dass dadurch entsteht, dass die Header normalerweise nicht Schnittstelle sondern Definition sind:
Pimpl Pointer

http://www.boost.org/more/report-jan-2006.html (ein bisschen runterscrollen. Muss man sich leider downloaden)

ps: das ist übrigens eines der Beispiele warum c++ doch die geilste sprache ist