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

[hustbaer]

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

und natürlich kommt noch dazu, dass ein C++ compiler pro source-file viel mehr machen muss, als ein Java compiler. nämlich üblicherweise hunderte header-files laden und komplett durchparsen.

[DStefan]

warum????? schrieb:

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

Damit ich zwischendurch auch mal Zeit habe, eine zu rauchen.

Stefan.

[Tippgeber]

warum????? schrieb:

Das hier compiliert, aber wer braucht sowas?

int main()
{
	int foo(int bla);

	int i=1;
	switch(i){
		while(i)
		{
			i--;
		}
		case 1:
			break;
	}
	if(foo(i), i) i++;
}

Wozu braucht man Funktionsdeklarationen in Funktionen? Wieso kann man ein while so in ein switch schreiben? Wozu braucht man Komma-Operatoren? Man hätte for-Schleifen auch so definieren können for(int i = 0, i<10, i++) und dann sowas, wenn mans will for(int i = 0, i<10, i++;j++). Wären Compiler nicht viel einfacher, wenn man auf so exotisches Zeug verzichtet hätte?

Wenn dir klar ist wie in Switch in Maschinencode übersetzt wird, dann ist das Verhalten nicht mehr so eigenartig. Alles in den geschweiften Klammern eines Switch-Statements ist ein großer Code-Block und die Case-Anweisungen sind Labels, so wie du sie auch mit dem goto-Statement benutzen würdest. Der einzige unterschied: der Wert der bei Auswertung des Ausdrucks in der Klammer von switch() heraus kommt wird mit allen Werten an den Labels verglichen und dann an das entsprechende Label gesprungen.
Kurz: switch ist so eigenartig damit der Compiler weniger tun muss.

[u-ser_l]

Damit ich zwischendurch auch mal Zeit habe, eine zu rauchen.

ach, du bist da dran schuld

Gut, daß du nicht Zigarre rauchst

[Bashar]

DStefan schrieb:

warum????? schrieb:

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

Damit ich zwischendurch auch mal Zeit habe, eine zu rauchen.

http://xkcd.com/303/

[Depressiv]

Lol, das hat mich jetzt aufgemuntert.

[Zeus]

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?

Die Frage ist, warum ist Java so schneller! Ganz einfach, wegen der VM.

Libs als Jar oder class-Dateien, müssen nicht mehr durch den Parser sondern können direkt ausgelesen werden und verwendet werden. Und das Generieren des nativen Code entfällt zur Compilezeit.

[hustbaer]

Das hat mit der VM wenig zu tun.

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

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.

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.

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