Warum lassen C/C++ Compiler soviel Müll zu?

knivil

LOLBla schrieb:

In deinen 16 großen Projekten ist dir also noch nie sowas wie z.B. IncrediBuild begegnet, sag ja einiges über deine Erfahrung mit großen Projekten aus...

Aeh haeh, wer sagt das? Ich zitiere mich mal selbst:

Man kompiliert meist inkrementell wenn man seinen eigenen Code testet.

Auch hilft dir IncrediBuild wenig, wenn 10 Entwickler ihre Aenderungen einschecken. Auch ist die Idee wohl eher alt.

Jaja, ich weiss: Don't feed the trolls! Aber ich habe heute ist mein Wohltaetigkeitstag fuer alle Trolle. Sie wuerden ja sonst verhungern. Naechstes Jahr bringe ich ihnen lesen bei ...

Was laberst du dann, dass du bei google nichts findest?

Basher_ist_nicht_BashAr

knivil schrieb:

wenn du einen kommentar in eine zentrale header-datei einfügst. schon muss alles neu gebaut werden, das diesen header #includiert.

Bei Java ist das anders? Wie unterscheidet er zwischen Kommentar und Aenderung einer Methodensignatur?

in Java gibts keine header-files, die überall includiert werden müssen. wenn du z.b. per refactoring 'ne signatur einer methode änderst, die an mehreren stellen benutzt wird, dann müssen natürlich auch diese files neu compiliert werden. theoretisch könnte das build-system bzw. die IDE erkennen, dass nur ein kommentar geändert wurde und die datei nicht zum compiler schicken. aber ich glaub' nicht, dass sowas sinnvoll wäre, weil das compilieren sowieso schon rasend schnell ist.

knivil

Und theoretisch ist das auch nicht spezifisch fuer Java.

knivil schrieb:

Man kompiliert meist inkrementell wenn man seinen eigenen Code testet.

Auch hilft dir IncrediBuild wenig, wenn 10 Entwickler ihre Aenderungen einschecken. Auch ist die Idee wohl eher alt.

Was laberst du eigentlich für zusammenhangloses Zeug? Was hat IncrediBuild damit zu tun wieviel Leute was einchecken?

hustbaer

Ich weiss nicht was ihr hier als schnell oder langsam empfindet. Ich finde es persönlich sehr störend, wenn ein Teil eines Projekts (soll heissen: eine DLL, LIB oder EXE) schon mehrere Minuten braucht. Und Build-Zeiten von mehreren Minuten hat man bei C++ schnell. Eine unserer grösseren Libraries baut z.B. schonmal 10 Minuten. Wenn ein gesamtes Projekt neu gebaut werden muss (z.B. weil es eine Änderung in einer Basis-Library gab, die sogut wie überall verwendet wird), dauert das auch schon mal ne Stunde oder zwei.

@knivil:
C Build-Zeiten (Linux Kernel) mit C++ Build-Zeiten zu vergleichen ist wohl ziemlich weltfremd.
Genauso was die nightly Builds angeht: was bringt mir das, wenn ich trotzdem 5 Minuten warten muss, bis der Teil an dem ich arbeite fertig gebaut hat? Oder meinst du es beschleunigt das Arbeiten irgendwie wenn ich bis zum nächsten Tag arbeiten muss, um das Ergebnis eines Builds zu sehen.

audacia

hustbaer schrieb:

warum????? schrieb:

Zeus schrieb:

Wegen der Rekursion in der Grammatik. IfStatement, WhileStatement sind Statement und hinter dem Kopf darfst du weitere Statements schreiben - recht einfach. Aber verhindert halt nicht, das schreiben vom dummen Code.

Aber warum braucht C++ Code dann soviel länger zum Compilieren als Java Code, der eigentlich viel eingeschränkter ist?

weil C++ viel komplizierter zu compilieren ist als Java.

argument dependent lookup, implizite konvertierungen, templates, overload resolution -> in kombination ist das viel arbeit für einen compiler

Das machts alles nicht aus; ein guter C++-Compiler kann durchaus die Geschwindigkeit eines Delphi-/Java-/C#-/Whatever-Compilers erreichen. Ausschlaggebend ist primär die Menge.

Basher schrieb:

volkard schrieb:

ich frage mal andersrum. warum ist ein brainfuck-compiler so verdammt schnell?

wahrscheinlich weil der befehlssatz sehr klein ist und weil ein bf-programm meistens nur aus einer datei besteht. ok, möglicherweise frisst bei C++ die optimierung des codes auch schon einiges an rechenzeit. ein reiner C-compiler ist auch nicht sehr schnell, im vergleich zu Java-compilern, die dagegen reine raketen sind.

Kommt natürlich darauf an, wie du Schnelligkeit mißt. Wenn du den Zeilendurchsatz betrachtest, gewinnt der C- oder C++-Compiler meistens. Beispielsweise ist der Zeilendurchsatz von BCC (dem C++Builder-Compiler) schätzungsweise achtmal so hoch wie der von DCC (dem Delphi-Compiler). Dennoch kann die Übersetzungszeit eines größeren C++-Projektes in die Stunden gehen, während man bei kleineren Delphi-Projekten vom Kompiliervorgang überhaupt nichts mitbekommt, und selbst bei größeren Komponentenpackages oder Bibliotheken (SynEdit, JCL, JVCL, ...) wartest du schlimmstenfalls Sekunden auf ein vollständiges Rebuild. Ursache ist, daß die Zeilenzahl einer vom Präprozessor behandelte C++-Übersetzungseinheit gewöhnlich sechs- oder siebenstellig ist. Bei C ist das Grundproblem ebenfalls vorhanden, aber C-Header haben üblicherweise ganz andere Dimensionen als C++-Header. Beispiel:

/* c.c */
#include <stdio.h>

/* cpp.cpp */
#include <iostream>

>cpp32 c.c > nul
>wc -l < c.i
1027

>cpp32 cpp.cpp > nul
>wc -l < cpp.i
29359

Vorteil der Angelegenheit ist, daß sich die Kompilierung von C++-Projekten ohne zusätzlichen Aufwand parallelisieren läßt. Das ist bei Delphi nicht ganz so einfach, da die Abhängigkeiten der Units voneinander ein recht verwachsener Graph sind; nur wenige Units haben keine direkte oder indirekte Abhängigkeit voneinander und können dann gleichzeitig kompiliert werden.

Um dem Problem in der Praxis zu begegnen, verwendet man in C++ üblicherweise die bereits erwähnten PCH (pre-compiled headers). BCC generiert z.B. bei entsprechender Konfiguration implizit PCHs, und C++Builder enthält einen PCH-Wizard, der einen für ein einzelnes Projekt optimierten Master-Header zusammenstellen kann. Wenn PCHs richtig eingesetzt werden, werden die Build-Zeiten von C++-Projekten auch sehr überschaubar.

Zeus schrieb:

hustbaer schrieb:

Ein ähnliches Übersetzungsmodell liesse sich für C++ auch machen. Allerdings müsste man dann einige Dinge in der Sprache umkrempeln. Und das wird nicht passieren, da jeder so weit wie möglich zum Standard kompatibel bleiben möchte.

Dann mach mal.

Für C++ wurde ja bereits ein Modul-Konzept vorgeschlagen. Was daraus wird, weiß ich nicht - vielleicht TR1 oder TR2 des neuen Standards? -, aber es sollte unter anderem dieses Problem beheben.

knivil schrieb:

was hat das auseinanderreissen von klassen in zwei dateien (.h und .cpp) mit vernünftigem design zu tun?

Ich oeffne die Headerdatei und sehe die Methoden der Klasse uebersichtlich auf einem Fleck, wenn moeglich noch mit etwas Dokumentation wie Vor- und Nachbedingungen. Wenn ich eine Klasse benutze, so ist die Headerdatei meist in einem zweiten Fenster (naja, so etwas aehnliches) offen. Beim schreiben/designen/denken von Code reicht ein kurzer Blick, ganz ohne auf Tools angewiesen zu sein. Codecompletion, die als Menue aufpopt, ist viel langsamer als ein kurzer Blick, auch ist das Popup klein und bietet nicht die Uebersicht wie ein grosses Fenster. Ganz zu schweigen von den hilfreichen Kommentaren/Beschreibungen/Vor-/Nachbedingungen. Diese Uebersicht kann man mit Headerdateien unter Verwendung eines normalen Editors haben ganz ohne Toolsupport.

+1. Finde ich auch in Delphi (interface/implementation) deutlich angenehmer.

Wie man das header-implementierung design gutfinden kann bleibt mir ein rätsel. Das ganze system wurde doch nur gebaut um dem compiler die arbeit zu erleichtern und nicht dem programmierer. schon vor 30 jahren war das system unzumutbar und kein ernstzunehmender entwickler will mit sowas freiwillig zu tun haben. *kopfschüttel*

Antoras

Ich versteh ehrlich gesagt auch nicht wie man in der heutigen Zeit noch mit Editoren programmieren kann. In einer Sprache wie Java ist es unumgänglich eine IDE zu benutzen, andernfalls ist es fast unmöglich überhaupt den Code überhaupt noch überblicken zu können.
Allein schon die Tatsache, dass praktisch jeder professionelle Javaentwickler eine IDE einsetzt, sollte zumindest allen, die einer IDE nicht vorurteilslos gegenüberstehen, zu denken geben. Eine IDE hilft mir ja nicht nur den Überblick zu bewahren, sie unterstützen mich aktiv bei der Entwicklung. Beispielsweise beherrscht jede gute Java-IDE das Feature, Fehler im Code sofort anzuzeigen. Mit solchen IDEs ist es unmöglich syntaxtechnisch fehlerhaften Sourcecode zu kompilieren. Weiter haben Javadocs gezeigt, dass es auch möglich ist Kommentare zu kreieren, die beschreiben was eine Methode/Klasse/was-auch-immer macht. Das Argument, dass beim Arbeiten mit einer IDE Informationen verloren gehen ist deshalb nicht korrekt. Due Liste mit Vorteilen gegnüber eines Editor ließe sich ewig fortführen - ich bezweifle, dass es Argumente gibt, die so bedeutsam sind, dass man sich gegen eine solche entscheiden sollte (mit Ausnahme von der Tatsache, dass es für C/C++ keine vernünftige IDE gibt).
Deshalb bin ich auch der Meinung, dass jeder, der meint, dass die Features einer IDE unnütz sind, noch nie eine solche produktiv genutzt hat.

Das mag bei C anders sein, da ich dort keine so komplexe Datenstrukturen hab wie in Java. Und selbst C++ kann mit dem Klassenaufbau von Java nicht mithalten. Dennoch sollte es für keinen C/C++-Entwickler ein Hindernis darstellen sich mal eine IDE anzuschauen.

Über den Sinn von Headerdateien hab ich nur zu sagen, dass C/C++komplett anders aufgebaut sind als Java. Imho würde man wirklich den Überblick über den Sourcecode-Aufbau eines Programms verlieren.

volkard

Antoras schrieb:

Ich versteh ehrlich gesagt auch nicht wie man in der heutigen Zeit noch mit Editoren programmieren kann.

PHP oder Perl programmiere ich immer ohne IDE. Ich vermeisse auch keine.

Antoras schrieb:

In einer Sprache wie Java ist es unumgänglich eine IDE zu benutzen, andernfalls ist es fast unmöglich überhaupt den Code überhaupt noch überblicken zu können.

Ja, Java zu programmieren tendiert zu unübersichtlichem Code, wo man ohne IDE verloren wäre.

Antoras schrieb:

Allein schon die Tatsache, dass praktisch jeder professionelle Javaentwickler eine IDE einsetzt, sollte zumindest allen, die einer IDE nicht vorurteilslos gegenüberstehen, zu denken geben.

Es gibt mir zu denken. Vielleicht eine halbe Sekunde lang.

Antoras schrieb:

Eine IDE hilft mir ja nicht nur den Überblick zu bewahren, sie unterstützen mich aktiv bei der Entwicklung. Beispielsweise beherrscht jede gute Java-IDE das Feature, Fehler im Code sofort anzuzeigen. Mit solchen IDEs ist es unmöglich syntaxtechnisch fehlerhaften Sourcecode zu kompilieren.

In C++ stopfen wir diese Tests in den Quellcode rein, wir sind überzeugt, daß man mindestens 90% der Entwicklungszeit mit der Fehlersuche verbringt und stopfen Fehlersuchvereinfachungsfeatures in die Sprache, auch wenn die Sprache danach ein wenig verhackstückelt aussieht.

Antoras schrieb:

Weiter haben Javadocs gezeigt, dass es auch möglich ist Kommentare zu kreieren, die beschreiben was eine Methode/Klasse/was-auch-immer macht. Das Argument, dass beim Arbeiten mit einer IDE Informationen verloren gehen ist deshalb nicht korrekt. Due Liste mit Vorteilen gegnüber eines Editor ließe sich ewig fortführen - ich bezweifle, dass es Argumente gibt, die so bedeutsam sind, dass man sich gegen eine solche entscheiden sollte (mit Ausnahme von der Tatsache, dass es für C/C++ keine vernünftige IDE gibt).
Deshalb bin ich auch der Meinung, dass jeder, der meint, dass die Features einer IDE unnütz sind, noch nie eine solche produktiv genutzt hat.

Es wäre fair, wenn Du gute Java-Programmierer mit guten C++-Programmierern und schlechte Java-Programmierer mit schlechten C++-Programmierern vergleichen würdest.

[quote="Antoras"]Das mag bei C anders sein, da ich dort keine so komplexe Datenstrukturen hab wie in Java. Und selbst C++ kann mit dem Klassenaufbau von Java nicht mithalten. Dennoch sollte es für keinen C/C++-Entwickler ein Hindernis darstellen sich mal eine IDE anzuschauen.

C lassen wir mal außen vor. Das wird nur in Eck-Anwendungen verwendet.

[quote="Antoras"]Über den Sinn von Headerdateien hab ich nur zu sagen, dass C/C++komplett anders aufgebaut sind als Java. Imho würde man wirklich den Überblick über den Sourcecode-Aufbau eines Programms verlieren.

In Wahrheit benutzt jeder C++-Programmierer eine nette IDE. Zum Beispiel in MS-Dev-Studio läßt man sich die Klassen (nicht die Dateien!) in dem linken Fenster anzeigen. Wie der Editor es schafft, bei Doppelklick auf die Definitiopn zu kommen, bei inline-Def in die *.h, bei outline in die *.cpp, ist nicht mein Geschäft. Es klappt.

Sicherlichhat jeder C++-Programmierer oft ein Auge auf Java, weil da mal was einfacher geht. Aber die Trennung zischen *.h und *.cpp ist nicht dabei, die Trennungg ist nicht ganz unlogisch und wird einem darüberhinaus in der weiteren Arbeit von der IDE recht gut transparent wegillusioniert.

Zeus

audacia schrieb:

Zeus schrieb:

hustbaer schrieb:

Ein ähnliches Übersetzungsmodell liesse sich für C++ auch machen. Allerdings müsste man dann einige Dinge in der Sprache umkrempeln. Und das wird nicht passieren, da jeder so weit wie möglich zum Standard kompatibel bleiben möchte.

Dann mach mal.

Für C++ wurde ja bereits ein Modul-Konzept vorgeschlagen. Was daraus wird, weiß ich nicht - vielleicht TR1 oder TR2 des neuen Standards? -, aber es sollte unter anderem dieses Problem beheben.

Nicht nur das, es gibst auch ein Proposal für C++ für eine portable shared lib. Die Sache ist mal sollte Argumentation von der reale Welt und die, die Möglich trennen, weil das Prinzip anderes geht immer, wenns machbar ist, aber wer mach es?

Edit sry hab gerade nicht den ganze gelesen, werde ich nachholen wenn ich ganz nüchtern bin xD

volkard

Zeus schrieb:

werde ich nachholen wenn ich ganz nüchtern bin xD

FALLS es einen Grund gibt, nüchtern an so einem Thread teilzunehmen.

audacia

volkard schrieb:

Zum Beispiel in MS-Dev-Studio läßt man sich die Klassen (nicht die Dateien!) in dem linken Fenster anzeigen. Wie der Editor es schafft, bei Doppelklick auf die Definitiopn zu kommen, bei inline-Def in die *.h, bei outline in die *.cpp, ist nicht mein Geschäft. Es klappt.

(Die nötigen Informationen werden, soweit ich weiß, in der .ncb-Datenbank des Projektes gespeichert, die auch für IntelliSense verwendet wird. Entsprechend steigt und fällt die Aktualität der Information mit der von IntelliSense, das veränderte Dateien immer im Hintergrund parst. Ganz ähnlich dem, was der Class Explorer in der aktuellen C++Builder-Version macht (der übrigens auch Go to Definition kann).)

volkard schrieb:

Sicherlichhat jeder C++-Programmierer oft ein Auge auf Java, weil da mal was einfacher geht.

Und das ja nicht zu Unrecht. Eine moderne objektorientierte Hochsprache ohne das geringste Bißchen Reflection scheint einem schon manchmal etwas retardiert.

volkard

audacia schrieb:

volkard schrieb:

Sicherlichhat jeder C++-Programmierer oft ein Auge auf Java, weil da mal was einfacher geht.

Und das ja nicht zu Unrecht. Eine moderne objektorientierte Hochsprache ohne das geringste Bißchen Reflection scheint einem schon manchmal etwas retardiert.

Och, nöö. 99.93% der Programmiersachen gehen einfacher( ,womit auch fehlerfreier) und schneller ohne. Dann bleibt noch ein 0.07% großes Fenster für Reflection seitens der Sprache. Weitere 0.04% schafft keine Java-Ähnliche. Ups, C++ schafft alle, manchmal haut man halt einen C-Makro rein oder frickelt sonstwas.
Einigen wir uns mal drauf, daß Java eh außen vor ist, weil es ungefähr gar nichts kann zu enormen Kosten und das mit einer unglaublich bizarren Syntax im vergleich zum Erreichten.

Ich kann 100% fehlerfreie Software schreiben. Aber nur mit C++.

DEvent

volkard schrieb:

audacia schrieb:

volkard schrieb:

Sicherlichhat jeder C++-Programmierer oft ein Auge auf Java, weil da mal was einfacher geht.

Und das ja nicht zu Unrecht. Eine moderne objektorientierte Hochsprache ohne das geringste Bißchen Reflection scheint einem schon manchmal etwas retardiert.

Och, nöö. 99.93% der Programmiersachen gehen einfacher( ,womit auch fehlerfreier) und schneller ohne. Dann bleibt noch ein 0.07% großes Fenster für Reflection seitens der Sprache. Weitere 0.04% schafft keine Java-Ähnliche. Ups, C++ schafft alle, manchmal haut man halt einen C-Makro rein oder frickelt sonstwas.
Einigen wir uns mal drauf, daß Java eh außen vor ist, weil es ungefähr gar nichts kann zu enormen Kosten und das mit einer unglaublich bizarren Syntax im vergleich zum Erreichten.

Was auch immer
Immerhin muss ich nicht etliche Sekunden warten, wenn ich mal eine Header-Datei veraendert habe. Immerhin brauche ich keine Forward-Declerationen fuer Funktionen mehr (was auch ziemlich bescheuert ist). Ausserdem brauche ich keine nightly-builds, weil ich mein Projekt jederzeit kompilieren, testen und verpacken kann ohne eine Nacht warten zu muessen. Dazu gibt es mit maven ein Abhaenigkeitsmanagment, dass mir die benoetigten Bibliotheken automatisch aus dem Internet zieht, die Tests durchlaeuft, das Projekt verpackt und auf einen Server hochlaed. Als Pluspunkt kann ich mir jede Jar Datei runterladen und es sofort in mein Projekt benutzen, mach das mal mit einer vorkompelierten C/C++ Bibliothek.

PS: Die Syntax von Java koennte wirklich einfacher sein, wenn die Java-Leute closures in die Sprache einbauen wuerden.

volkard schrieb:

Antoras schrieb:

Eine IDE hilft mir ja nicht nur den Überblick zu bewahren, sie unterstützen mich aktiv bei der Entwicklung. Beispielsweise beherrscht jede gute Java-IDE das Feature, Fehler im Code sofort anzuzeigen. Mit solchen IDEs ist es unmöglich syntaxtechnisch fehlerhaften Sourcecode zu kompilieren.

In C++ stopfen wir diese Tests in den Quellcode rein, wir sind überzeugt, daß man mindestens 90% der Entwicklungszeit mit der Fehlersuche verbringt und stopfen Fehlersuchvereinfachungsfeatures in die Sprache, auch wenn die Sprache danach ein wenig verhackstückelt aussieht.

Dumm? Lern mal lesen.

knivil

Beispielsweise beherrscht jede gute Java-IDE das Feature, Fehler im Code sofort anzuzeigen ... unmöglich syntaxtechnisch fehlerhaften Sourcecode zu kompilieren

Aehm Vim zeigt auch Syntaxfehler an, aber auch javac kompiliert syntaktisch fehlerhaften Source auch nicht. Warum sollte es dann die IDE schaffen? Auch kommt ein Zeitpunkt, da macht man einfach keine syntaktischen Fehler. Ich verstehe dein Argument nicht.

Javadocs ... Das Argument, dass beim Arbeiten mit einer IDE Informationen verloren gehen ist deshalb nicht korrekt.

Behauptet niemand. Ich sage nur, sie sind nicht so unmittelbar verfuegbar. Auch gibt es das schon laenger fuer fast alle Programmiersprachen.

ich bezweifle, dass es Argumente gibt, die so bedeutsam sind, dass man sich gegen eine solche entscheiden sollte

Z.B. Eclipse ist einfach riesig. Hat viel Mist mit den ganzen plugins, die irgendwie nie miteinander zusammenarbeiten wollen. Mir gegenueber arbeiten die Leute mit irgendwelchen MDA-Tools und muessen sich bei plugins genau an der Versionnummer orientieren. Sie fluchen staendig.

IDE unnütz sind

Wer behauptet das? Auch koennte man sagen: Wer noch nie einen anstaendigen Editor benutzt, kann ihn gar nicht zu schaetzen wissen. Wie ich solche Argumente liebe. Aber du hast recht, obwohl ich durchaus Eclipse benutzen musste, habe ich diese IDE nicht wirklich produktiv einsetzen koennen.

Das mag bei C anders sein, da ich dort keine so komplexe Datenstrukturen hab wie in Java. Und selbst C++ kann mit dem Klassenaufbau von Java nicht mithalten.

Aeh, das halte ich fuer groben Unfug.

Einigen wir uns mal drauf, daß Java eh außen vor ist, weil es ungefähr gar nichts kann zu enormen Kosten und das mit einer unglaublich bizarren Syntax im vergleich zum Erreichten.

Ganz so ist es nicht, aber es hat mich trotzdem erheitert.

knivil schrieb:

IDE unnütz sind

Wer behauptet das? Auch koennte man sagen: Wer noch nie einen anstaendigen Editor benutzt, kann ihn gar nicht zu schaetzen wissen. Wie ich solche Argumente liebe. Aber du hast recht, obwohl ich durchaus Eclipse benutzen musste, habe ich diese IDE nicht wirklich produktiv einsetzen koennen.

Der Troll-Award für bestes Zitate auseinander reißen geht an knivil.

knivil

Ja im Orginal wird von Features gesprochen. Aber eine IDE definiert sich ueber ihre Features. Also wenn die Features unnuetz sind, so ist es die IDE auch. Und wenn die IDE unnuetz ist, hat sie auch keine nuetzlichen Features. Also: unnuetze IDE <=> alle Features der IDE unnuetz. Wird also eine Aussage ueber das eine gemacht, trifft diese Aussage auch auf das andere zu (es sei mal dahingestellt, ob diese Aussage richtig oder falsch (oder meinungsabhaengig) ist). Was ist an dieser Logik falsch?