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

[Zeus]

hustbaer schrieb:

Das hat mit der VM wenig zu tun.

Ja, ne, ich hab die Frage umgedreht und anhand der zugrundelegende Infrastruktur argumentiert - also wenn das nicht mit der VM zu tun hat, warum ist das Kompilieren in Java so schnell?

hustbaer schrieb:

Das Generieren von "native Code" ist kein sehr teurer Schritt. Ob jetzt "hochoptimierter" Bytecode oder "hochoptimierter" Maschinencode für irgendeine reale CPU erzeugt wird, ist ziemlich egal.
Klar, bei Java werden gewisse Optimierungen komplett in den JITer ausgelagert, aber die sind nicht wirklich so teuer. Sonst würde das Programm ja "ewig" beim Starten brauchen (was Java Programme nicht wirklich tun - lange ja, aber nicht "ewig" ).

Ja klein Vieh mach auch Mist.

hustbaer schrieb:

Und die Sache mit der .jar Files - dafür ist auch keine VM nötig. Das geht genauso schön mit Native Code. Man sehe sich bloss mal die Type-Libraries bei COM an.

COM goes overall!

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.

[u-ser_l]

außerdem läßt sich C++ nicht mit lookahead-LR (LALR) parsen, java aber schon - und LALR-Parsing ist hocheffizient.

[Basher_ist_nicht_BashAr]

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.

macht nicht mickrigweich schon sowas mit c++/cli bzw. managed-c++ (oder wie sie es nennen) für ihre .NET plattform?

u-ser_l schrieb:

außerdem läßt sich C++ nicht mit lookahead-LR (LALR) parsen, java aber schon - und LALR-Parsing ist hocheffizient.

das hängt vielleicht damit zusammen, dass man unter c++ alles doppelt hat, die klassendefinition in .h-files und den code in .cpp-files. sowas ist doch ziemlich doof. warum kann man in c++ nicht definition und implementation in einer datei haben? in Java geht's doch auch.

[volkard]

Basher schrieb:

warum kann man in c++ nicht definition und implementation in einer datei haben? in Java geht's doch auch.

Kann man doch. Nur werden dann die Compilezeiten ein oder zwei geringfügige Größenordnungen länger.

[Basher_ist_nicht_BashAr]

volkard schrieb:

Basher schrieb:

warum kann man in c++ nicht definition und implementation in einer datei haben? in Java geht's doch auch.

Kann man doch. Nur werden dann die Compilezeiten ein oder zwei geringfügige Größenordnungen länger.

aber warum dauert es so verdammt lange? liegt es am compiler oder braucht der linker die meiste zeit?

[volkard]

Basher schrieb:

volkard schrieb:

Basher schrieb:

warum kann man in c++ nicht definition und implementation in einer datei haben? in Java geht's doch auch.

Kann man doch. Nur werden dann die Compilezeiten ein oder zwei geringfügige Größenordnungen länger.

aber warum dauert es so verdammt lange? liegt es am compiler oder braucht der linker die meiste zeit?

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

[Zeus]

Brainfuck aka Minimal-Bytecode *gg*

[Basher_ist_nicht_BashAr]

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.

[typischdummm]

Zeus schrieb:

hustbaer schrieb:

Das hat mit der VM wenig zu tun.

Ja, ne, ich hab die Frage umgedreht und anhand der zugrundelegende Infrastruktur argumentiert - also wenn das nicht mit der VM zu tun hat, warum ist das Kompilieren in Java so schnell?

hustbaer schrieb:

Das Generieren von "native Code" ist kein sehr teurer Schritt. Ob jetzt "hochoptimierter" Bytecode oder "hochoptimierter" Maschinencode für irgendeine reale CPU erzeugt wird, ist ziemlich egal.
Klar, bei Java werden gewisse Optimierungen komplett in den JITer ausgelagert, aber die sind nicht wirklich so teuer. Sonst würde das Programm ja "ewig" beim Starten brauchen (was Java Programme nicht wirklich tun - lange ja, aber nicht "ewig" ).

Ja klein Vieh mach auch Mist.

hustbaer schrieb:

Und die Sache mit der .jar Files - dafür ist auch keine VM nötig. Das geht genauso schön mit Native Code. Man sehe sich bloss mal die Type-Libraries bei COM an.

COM goes overall!

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.

irgendwas musstest du jetzt zu deiner verteidigung überall noch hinschreiben, auch wenn es nur deine dummheit unterstreicht.

[u-ser_l]

Basher schrieb:

das hängt vielleicht damit zusammen, dass man unter c++ alles doppelt hat, die klassendefinition in .h-files und den code in .cpp-files.

es hat wohl was mit lokalen Typdefinitionen zu tun, die dafür sorgen, daß bereits der Lexer Metainformationen aus der Symboltabelle braucht, die erst der Parser liefert oder so was in der Art.

Jedenfalls gilt Parsing von C++ als außerordentlich schwieriges Problem, weitaus schwieriger als bei vielen anderen Sprachen mit weniger umfangreichen und verwinkelten Sprachdefinitionen. Deshalb ja auch die Schwierigkeit der Behandlung von C++ code mit Refactoring und anderen Meta-Methoden.

[knivil]

Basher schrieb:

das hängt vielleicht damit zusammen, dass man unter c++ alles doppelt hat, die klassendefinition in .h-files und den code in .cpp-files.

Bullshit! Und wenn es so waere wuerde ich die Compilezeit gerne in Anspruch nehmen, um ein vernuenftiges Design zu ermoeglichen. Jetzt wird nicht mehr auf der Sprache rumgehackt, sondern schon auf die Kompilierzeiten ... In groesseren Projekten wird sowieso alles ueber Nacht gebaut, so dass es eigentlich egal ist.

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

Weil sie kein Ersatz fuer brain.exe sind.

[LOLBla]

knivil schrieb:

In groesseren Projekten wird sowieso alles ueber Nacht gebaut, so dass es eigentlich egal ist.

Klar, die Entwickler compilieren einfach nichts, sondern checken ihren Code einfach ein.

[u-ser_l]

und wenn eine Zeile wegen eines vergessenen Semikolons mal nicht compilieren sollte, fügt man das Zeichen ein und wartet halt bis zur nächsten Nacht - bloß kein Streß

[knivil]

LOLBla schrieb:

knivil schrieb:

In groesseren Projekten wird sowieso alles ueber Nacht gebaut, so dass es eigentlich egal ist.

Klar, die Entwickler compilieren einfach nichts, sondern checken ihren Code einfach ein.

Und wie viel ist das so an Zeilen, den ein Entwickler am Tag neu kompilieren muss? Wie viel Zeit geht dabei drauf? Spielt das eine Rolle? Normalerweise nicht.

[LOLBla]

knivil schrieb:

LOLBla schrieb:

knivil schrieb:

In groesseren Projekten wird sowieso alles ueber Nacht gebaut, so dass es eigentlich egal ist.

Klar, die Entwickler compilieren einfach nichts, sondern checken ihren Code einfach ein.

Und wie viel ist das so an Zeilen, den ein Entwickler am Tag neu kompilieren muss? Wie viel Zeit geht dabei drauf? Spielt das eine Rolle? Normalerweise nicht.

An welchem größeren Projekt hast du schon mitgearbeitet?

[knivil]

LOLBla schrieb:

An welchem größeren Projekt hast du schon mitgearbeitet?

Was ist ein groesseres Projekt? Wie gross sollte der Eigenanteil sein? Wie lange darf die Entwicklungszeit sein? Welche Sprache? GUI oder Algorithmus (Core, Netzwerkkommunikation, ...)? Zaehlt eine Eclipse-Plugin (nein, das habe ich nicht gemacht)? ... Und was soll das beweisen?

PS: Es sind 16 und nu?

[Beobachter]

Wenn ich einen kompletten Rebuild des Linux-Kernels mache, dann geht das recht flott, wenn man die Größe bedenkt. Wenn ich ihn schon einmal kompiliert habe, dann sind kleinere Änderungen recht schnell kompiliert.
Und wie in jedem ordentlich entworfenen Projekt dieser Größe kann ich auch nur Teile neu kompilieren, sprich den Teil an dem ich arbeite.

Fazit: bei einem großen C oder C++ Projekt ist ein gut entworfenes Build-System das A und O.

[Basher_ist_nicht_BashAr]

knivil schrieb:

Basher schrieb:

das hängt vielleicht damit zusammen, dass man unter c++ alles doppelt hat, die klassendefinition in .h-files und den code in .cpp-files.

Bullshit! Und wenn es so waere wuerde ich die Compilezeit gerne in Anspruch nehmen, um ein vernuenftiges Design zu ermoeglichen.

was hat das auseinanderreissen von klassen in zwei dateien (.h und .cpp) mit vernünftigem design zu tun? pro klasse immer 2 dateien synchron pflegen zu müssen, ist umständlicher, als hätte man nur eine. einfach doof sowas.

knivil schrieb:

In groesseren Projekten wird sowieso alles ueber Nacht gebaut, so dass es eigentlich egal ist.

ok, einen vorteil hat es ja: durch diese übelst langen build-zeiten bei grossen projekten, ist man gezwungen, für einzelkomponenten unit-tests o.ä. zu schreiben. sowas fördet natürlich die stabilität des codes, gute schnittstellendefinitionen und planvolles design. bei anderen sprachen muss man dafür selbstdisziplin aufbringen.

[knivil]

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.

pro klasse immer 2 dateien synchron pflegen zu müssen, ist umständlicher, als hätte man nur eine. einfach doof sowas.

Datenmember schon mal nicht. Auch hatte ich nie Probleme damit.

ok, einen vorteil hat es ja: durch diese übelst langen ...

Jaja, wer argumentiert hat schon verloren ... warum probiere ich es ueberhaupt. Man kompiliert meist inkrementell wenn man seinen eigenen Code testet. Wie lange braucht es, 5000 Zeilen normalen C++ Code zu kompilieren (Templates mal aussen vor, da ich Endlosschleifen produzieren kann)?

[Basher_ist_nicht_BashAr]

knivil schrieb:

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.

^^das gilt aber nur, wenn man editoren wie notepad verwendet. ich glaube, jedem schäbigen 'vim' kannste heutzutage beibringen, dass er methodenkörper usw. auf- und zuklappen kann.

knivil schrieb:

ok, einen vorteil hat es ja: durch diese übelst langen ...

Jaja, wer argumentiert hat schon verloren ... warum probiere ich es ueberhaupt. Man kompiliert meist inkrementell wenn man seinen eigenen Code testet.

klar, der msvc z.b. kennt auch schon lange sowas wie 'precompiled headers' und andere tricks, um den build-vorgang zu beschleunigen. aber trotzdem hört man immer wieder, dass das bauen eines grossen projekts sehr lange dauert (und über nacht gemacht wird!). es reicht ja schon, wenn du einen kommentar in eine zentrale header-datei einfügst. schon muss alles neu gebaut werden, das diesen header #includiert.