Haben Headerdateien eigentlich Vorteile?

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