Haben Headerdateien eigentlich Vorteile?

kartoffelsack schrieb:

Das Header-Konzept ist in C++ inhärent notwendig um Sprachidiome zu ermöglichen die es in anderen Sprachen so nicht gibt:

- Objekte auf dem Stack. [...]

In C# kannst du auch Instanzen von Klassen auf dem Stack allokieren, und Instanzen von structs werden sogar immer auf dem Stack allokiert. Der technische Unterschied ist einfach das Linking zur Laufzeit. Wenn eine Methode zum ersten mal aufgerufen und JIT-compiliert wird, kann der JIT-compiler sich ohne Probleme die Klassendefinition ansehen und die Größe erkennen. Die ganze Klassendefinition steht dem JITer zur Verfügung und das, was in C++ ein Header ist, braucht man schlicht nicht, weil die statischen Compiler die Größe der Typen nicht kennen müssen (denn sie erzeugen nicht den Maschinencode).

daHa

auch durch das staendige wiederhohlen von halbwahrheiten und halbragen zeug werden diese nicht richtiger bzw werden zu brauchbaren nachvollziehbaren argumenten

Optimizer schrieb:

Sie verraten mehr über die Implementierung, wenn ich nicht zusätzlichen Aufwand betreibe, um diese zu verstecken.

wie aufwendig es ist hab ich beschrieben, laesst du das nicht gelten weil IDE unterstuetzt?

Optimizer schrieb:

Die include-Reihenfolge kann wichtig sein (wie scheiße ist das?!).

ich ersuche dich um praxisrelevatne beispiele die die includereihenfolge zum problem machen.

sachen ala

Optimizer schrieb:

Wenn jemand ein Depp ist, macht er in den Header Makros, using-Direktiven oder sonstwas rein, was mit meinem Quellcode dann in Konflikt steht. Wie schlecht ist das textuelle includen eigentlich?

gelten nicht, wenn man problem code erbt, dann ist das sprachunabhaenig ein problem.

ich bin sicher, ein depp kann auch in java c# sonstigen so programmieren das es fuer andere die damit arbeiten muessen zum problem wird.

Optimizer schrieb:

Die Liste ist wirklich endlos - kann man nicht einfach mal einsehen, dass es ein Konzept aus der Computer-Steinzeit ist und dass es suckt?

die endlose liste seh ich nicht.
header ham lange nicht alle nachteile die du ihnen unterstellst, und in der realtiaet werden mit diesen mitteln noch sehr brauchbare sachen gemacht.
lauter deppen die noch nicht auf die wahre religion umgestiegen sind?

Optimizer schrieb:

Ich flame jetzt wirklich nicht rum nach dem Motto "C++ ist scheiße, Java ist geil"

aso?

Optimizer schrieb:

aber man kann doch wirklich mal einsehen, dass das Übersetzungsmodell mit allem, was dazu gehört, einschließlich Headerfiles, einschließlich endlosen Übersetzungszeiten auf Grund mangelnder Schnittstellenprüfung unglaublich schlecht ist. Und die riesigen Compilerfarmen mit endlos langen Übersetzungszeiten geben mir in diesem Punkt sicherlich auch recht. Ich habe noch nie gesehen, dass man Tage braucht, um ein Java-Programm zu compilieren.

wie praxis und ergebnis relevant sind die uebersetzungszeiten?

wuerdest du mir bitte den faktor nennen um welchen java c# oder sonstige sachen schneller kompilieren?
am besten an hand gleichwertiger programme, einen kernel mit hello word vergleich is witzlos.

und sind scriptsprachen besser weil sie noch schneller ausfuehrbare sachen bringen, ganz ohne exta compiler?

und wuerdest du mir bitte beispiele nennen wofuer die riesigen compilerframen gebraucht werden,

und wenn dir ein Bsp eingefallen ist wofuer comilerframen gebraucht werden, wo sind die moderneren loesungen sind mit denen man diese framen abschaffen kann und warum wurde das nicht gemacht?

wie aufwendig es ist hab ich beschrieben, laesst du das nicht gelten weil IDE unterstuetzt?

Es geht hier um die angesprochenen Proxies und ich kenne keine IDE, die das für mich generiert. Überhaupt kenne ich nicht viele IDEs, die mir die Arbeit mit Headern nennenswert abnehmen. Und überhaupt sind jetzt Proxies immer noch nicht geil, sondern nur was hässliches, was ich brauche, weil das Übersetzungsmodell halt doch nicht so toll ist.

ich ersuche dich um praxisrelevatne beispiele die die includereihenfolge zum problem machen.

Finde selber was. Dieses Problem hatte jeder schon einmal. Es sagt keiner, dass es nicht lösbar ist, aber es ist scheiße.

Optimizer schrieb:

Wenn jemand ein Depp ist, macht er in den Header Makros, using-Direktiven oder sonstwas rein, was mit meinem Quellcode dann in Konflikt steht. Wie schlecht ist das textuelle includen eigentlich?

gelten nicht, wenn man problem code erbt, dann ist das sprachunabhaenig ein problem.

ich bin sicher, ein depp kann auch in java c# sonstigen so programmieren das es fuer andere die damit arbeiten muessen zum problem wird.

Dann dreh es halt um und geh von fähigen Programmierern aus. Wie schlecht ist es, in Headern nicht using benutzen zu können? Wie schlecht ist es, ständig voll qualifizierte Namen auszuschreiben, die zusammen mit Templates dann alleine schon eine Zeile füllen? Jetzt sagst du einfach "schlechte Programmierer zählen nicht", hast aber nicht näher ausgeführt, was passiert, wenn die Programmierer die Problematik kennen. Oder wolltest du darauf vielleicht nicht eingehen? Ist es doch nicht so vorteilhaft, wenn man vorgeschrieben bekommt, man darf dieses und jenes nicht benutzen und muss stattdessen jedesmal template<class IndexType> typename IndexType::const_iterator (man beachte, dies ist ein sehr harmloser templatisierter typ) ausschreiben? Ach was red ich, du wirst eh einfach nur sagen "das ist nicht schlimm", anscheinend interessiert dich nicht, wenn es besser geht.

wie praxis und ergebnis relevant sind die uebersetzungszeiten?

Sehr. Große Programme wie kommerzielle Spiele und Betriebssysteme oder nur Kernels brauchen Stunden und Tage, um übersetzt zu werden.

wuerdest du mir bitte den faktor nennen um welchen java c# oder sonstige sachen schneller kompilieren?
am besten an hand gleichwertiger programme, einen kernel mit hello word vergleich is witzlos.

Hier geht es nicht um einen konstanten Faktor. Bei allen modernen Übersetzungsmodellen bist du um Größenordnungen schneller. Dass du solche Fragen stellst, zeigt nur eins: Du weißt es einfach nicht, willst es nicht wahrhaben, glaubst es nicht, es ist aber so. Jeder, der irgendwann schon einmal etwas nur mittelgroßes geschrieben hat, merkt das sofort.

und sind scriptsprachen besser weil sie noch schneller ausfuehrbare sachen bringen, ganz ohne exta compiler?

Was hat das damit zu tun?

und wuerdest du mir bitte beispiele nennen wofuer die riesigen compilerframen gebraucht werden

Nein, mach selber. Sourceforge bietet dir ne Compilerfarm, wenn du mal eine brauchst.

auch durch das staendige wiederhohlen von halbwahrheiten und halbragen zeug werden diese nicht richtiger bzw werden zu brauchbaren nachvollziehbaren argumenten

Klar, es ist nicht schlecht, wenn ich mich um Firlefanz kümmern muss, anstatt programmieren zu können. Klar, es ist nicht schlecht, wenn ein Programm Tage zum übersetzen braucht und man ganze Compilerfarmen hinstellen muss. Du bist jetzt gerade so weit, dass du mit Header-Dateien zurecht kommst und daher mit einigen Nachteilen leben kannst. Fälschlicherweise stellst du das aber so hin, als gäbe es diese Nachteile nicht oder als wären sie nicht relevant. Was in den letzten Jahrzehnten nach der Entwicklung von C++ in Forschung über Compilerbau gesteckt wurde, weißt du einfach besser und kannst dank deiner endlosen Kompetenz Fakten als Halbwahrheiten hinstellen.

Wenn du dich mal mit dem Compilerbau befasst, wirst du auch mal feststellen, dass das Konzept der Header-Dateien seit 20 Jahren veraltet ist und nicht als tolle Interface-Darstellungshilfe der Programmierer entworfen wurde, sondern eine technische Notwendigkeit des Übersetzungsmodells war. Und dass diese Konzept praktisch nirgendwo mehr verfolgt wird. Für das, dass du wirklich keine nennenswerte Ahnung vom Thema hast, redest mit einer Ausdauer dagegen an, dass einem schlecht werden kann.

daHa

optimizer, ich nehm zur kentniss das viele deiner hinweise und argumente von dir selbst nicht durch praxisrelevante beispiele belegbar sind, wiedermal.

halbgarer mist den du von dir gibst, die meisten bsp die du bringst haben bestenfalls theoretische berechtigung, praktisch gleich null, fuers taegliche arbeiten irrelevant.

marketingmist und halbgare propaganda zum quatrat.

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.

dein einziges argument is neuer==besser, und daraus folgerst du das alles bisher gewesene alter scheiss ist.
welch zwingende logik, die du zwar nicht argumentieren kannst, ausser mit halbgaren geschwafel, aber das stoert dich nicht.

und nur preventiv, um unterstellungen vorzubeugen, ich schreib nicht das header ueberlegen sind, bzw module die symbolinfos einbinden mist sind.
ich relativer nur den mist den du von dir gibst, und anhand dessen du konzepte die nicht deiner bevorzugten religion folgen die lebensberechtigung absprechen willst bzw als scheisse bezeichnest.
und die dir helfen koennten die dir, von dir, gestellte frage zu beantworten warum noch nicht alle welt die alten konzepte verteufelt und der von dir bevorzugten religion folgt.

Hier ist keine Religion im Spiel. Seit C haben sich die Übesetzungsmodelle weiterentwickelt und mehr sage ich nicht.

Ich verteufel gar nichts, sondern appelliere nur daran, einzusehen, dass ein Übersetzungsmodell mit Header-Dateien aus heutiger Sicht veraltet und ungut ist. Das wird aber nicht eingesehen, stattdessen werden sie als etwas tolles und praktisches zur Übersichtlichkeit dargestellt.

Dass der Linux-Kernel Tage zum Übersetzen braucht, habe ich nicht behauptet. Wohl aber eine Zeit, die alles andere als genehm ist und wenn du eine komplette Distribution baust, bist du mit vielen Stunden dabei. Sowas gäbe es bei modernen Übersetzungsmodellen nicht, ob ganzes Betriebssystem hin oder her. Um den Unterschied zu begreifen, braucht man Ahnung vom Compilerbau, die du nicht hast. Mit Sicherheit hast du auch entsprechende Vorlesungen nie besucht oder nur darin geschlafen.

Header-Dateien sind aus der Mode, genauso wie du. Da dein letztes Posting nur noch fiese und unhaltbare Behauptungen und Unterstellungen enthält, steige ich hiermit aus.

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