Warum lassen C/C++ Compiler soviel Müll zu?
-
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.
-
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.
-
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?
-
knivil schrieb:
Was ist an dieser Logik falsch?
Ich verstehe nicht was diese Logik mit der unvollständigen Zitierung meines Beitrags zu tun haben soll.
volkard schrieb:
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.
Es macht einen kleinen Unterschied ob ich durch vorausschauendes Programmieren, oder durch sofortige Fehlersuche Fehler finde. Erstere umgeht man indem man einen Fehler ausgibt wenn das Programm bestimmte Ressourcen, die es zum arbeiten benötigt, nicht findet (Diese Fehlerbehandlung kann einem die IDE nicht abnehmen). Letztere umgeht man nur durch gründliches Durcharbeiten des Sourcecodes. Gemeint sind hier bspw. Rechtschreibfehler, die dazu führen, dass eine Funktion, die nicht existiert aufgerufen wird (Und die passieren jedem mal). Eine IDE zeigt mir so etwas sofort an und ich kann es beheben. Mit einem normalen Editor muss ich erst anfangen zu kompilieren, damit mir der Compiler den Fehler anzeigen kann.
knivil schrieb:
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.
Ich bestreite nicht, dass bei den IDEs auch viel unnützes Zeugs dabei ist - aber gerade die Menge des nützlichen ist es was eine IDE (vor allem das mir ans Herz gewachsene eclipse) von einem Editor abhebt. Zumahl man bei vim noch tausend Plugins installieren/anpassen muss bis man es als Ersatz zu einer IDE ansehen kann.
Autovervollstädigung, Debugger, Refactoring, sofortige Code-Formatierung, Versionsverwaltung, Profiler etc. sind Dinge die mir das Programmieren vereinfachen und die mich bei der Fehlersuche unterstützen. Ich finde es enorm praktisch alles in einem Programm zu haben. Wenn ich in C programmiere muss ich immer zehn unterschiedliche Programme bedienen. Zumahl ich für vim bisher keine Plugins gefunden haben, die mich so intuitiv beim Programmieren unterstützen, wie es eclipse tut.knivil schrieb:
Aeh, das halte ich fuer groben Unfug.
Schon mal in Java ein Interface-Objekt erstellt, das von hundert anderen Interfaces implementiert wird welche wiederum von mehrere Klassen implementiert werden, die wiederum mehrere erbende Klassen haben? Ohne IDE bekommst du nicht so ohne weitere raus welche Klassen nun ein Typ des obersten Interfaces sind und welche nicht.
volkard schrieb:
Ja, Java zu programmieren tendiert zu unübersichtlichem Code, wo man ohne IDE verloren wäre.
;fricky kritisierst du wegen seines Bashings - du machst es aber selbst nicht besser. Gehört zwar nicht zum Thema, wollte ich aber mal gesagt haben.
-
Antoras schrieb:
Gemeint sind hier bspw. Rechtschreibfehler, die dazu führen, dass eine Funktion, die nicht existiert aufgerufen wird (Und die passieren jedem mal). Eine IDE zeigt mir so etwas sofort an und ich kann es beheben. Mit einem normalen Editor muss ich erst anfangen zu kompilieren, damit mir der Compiler den Fehler anzeigen kann.
Und wenn die IDE nicht alles findet, hagelt es Exceptions zur Laufzeit. Natürlich ein paar davon beim Kunden. Sie kann eh nicht viel finden. In C++ schon gar nicht. Ich glaube, es würde mich nur verwirren, wenn die Hälfte der Tippfehler von der IDE angezeigt werden würden und die andere Hälfte vom Compiler.
Antoras schrieb:
volkard schrieb:
Ja, Java zu programmieren tendiert zu unübersichtlichem Code, wo man ohne IDE verloren wäre.
;fricky kritisierst du wegen seines Bashings - du machst es aber selbst nicht besser. Gehört zwar nicht zum Thema, wollte ich aber mal gesagt haben.
Kritik doch wegen des C++-Bashings.
Außerdem bin ich nur auf die Entführung des Threads eingegangen. Auf ein "Oh, Java ist so wunderbar." kann ich mich einfach nicht halten.
-
Antoras schrieb:
Es macht einen kleinen Unterschied ob ich durch vorausschauendes Programmieren, oder durch sofortige Fehlersuche Fehler finde. Erstere umgeht man indem man einen Fehler ausgibt wenn das Programm bestimmte Ressourcen, die es zum arbeiten benötigt, nicht findet (Diese Fehlerbehandlung kann einem die IDE nicht abnehmen). Letztere umgeht man nur durch gründliches Durcharbeiten des Sourcecodes. Gemeint sind hier bspw. Rechtschreibfehler,
In C++ versteht man unter vorausschauendem Programmieren etwas ganz anderes, als daß man eine Exception wirft, wenn ein eine Datei nicht da ist. Man versteht darunter, daß man seine niederen Funktionen so gestaltet, daß viele typische Programmierfehler zur Compilezeit herausgefischt werden. Falls Dir mal das Buch "Effektiv C++ programmieren" über den Weg läuft, schau schnell rein.
-
volkard schrieb:
Antoras schrieb:
Gemeint sind hier bspw. Rechtschreibfehler, die dazu führen, dass eine Funktion, die nicht existiert aufgerufen wird (Und die passieren jedem mal). Eine IDE zeigt mir so etwas sofort an und ich kann es beheben. Mit einem normalen Editor muss ich erst anfangen zu kompilieren, damit mir der Compiler den Fehler anzeigen kann.
Und wenn die IDE nicht alles findet, hagelt es Exceptions zur Laufzeit. Natürlich ein paar davon beim Kunden. Sie kann eh nicht viel finden. In C++ schon gar nicht. Ich glaube, es würde mich nur verwirren, wenn die Hälfte der Tippfehler von der IDE angezeigt werden würden und die andere Hälfte vom Compiler.
Dumm nur, dass die IDE einfach auch nen Compiler verwendet und somit alle Fehler findet und nicht nur die Hälfte. Vielleicht solltest du erst mal so ne Java IDE verwenden, vor du Vermutungen aufstellst.
-
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.
Wenn du Shareware oder Numbercrunching-Software entwickelst, mag das zutreffen.
volkard schrieb:
Ups, C++ schafft alle, manchmal haut man halt einen C-Makro rein oder frickelt sonstwas.
Versteh ich nicht.
volkard schrieb:
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.
Leicht übertrieben, aber nicht ganz falsch. Fürs Einigen ist es mir etwas zu stark formuliert
Jedenfalls tun sich C++ und Java in puncto syntaktischer Redundanz nicht viel, und auch die Performance einer Java-Anwendung ist viel näher an C++ denn an anderen modernen Sprachen. Die jeweiligen Schwächen der Sprachen liegen anderswo.
tja schrieb:
Vielleicht solltest du erst mal so ne Java IDE verwenden, vor du Vermutungen aufstellst.
+1.
-
audacia schrieb:
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.
Wenn man kaum templates verwendet mag das zutreffen.
-
hustbaer schrieb:
Wenn man kaum templates verwendet mag das zutreffen.
Das hatten wir schon:
knivil schrieb:
(Templates mal aussen vor, da ich Endlosschleifen produzieren kann)
-
ach ja, nochwas. ich glaube, was mir an c++ zuerst negativ aufgefallen ist: wie man statische klassenvariablen anlegen muss. einmal in der klassendefinition und dann noch mal ausserhalb. da hatte stroustrup wohl 'nen richtigen blackout, als er sich das einfallen liess.
-
Basher schrieb:
ach ja, nochwas. ich glaube, was mir an c++ zuerst negativ aufgefallen ist: wie man statische klassenvariablen anlegen muss. einmal in der klassendefinition und dann noch mal ausserhalb. da hatte stroustrup wohl 'nen richtigen blackout, als er sich das einfallen liess.
Im Header deklarieren. In der Implementierungsdatei definieren (=Speicherplatz besorgen). Ist doch in C genauso. Warum wundert Dich das?
-
volkard schrieb:
Im Header deklarieren. In der Implementierungsdatei definieren (=Speicherplatz besorgen). Ist doch in C genauso. Warum wundert Dich das?
in C gibts doch keine statischen struct-members. auch wenn C++ anfänglich eine erweiterung von C sein sollte, so macht es doch wenig sinn, sich bei etwas völlig neuem zu sehr an C zu orientieren.
btw, mas macht C++ eigentlich bei sizeof(cpp_klasse), werden statische members mitgezählt oder nicht?
-
btw, mas macht C++ eigentlich bei sizeof(cpp_klasse), werden statische members mitgezählt oder nicht?
Probiere es aus! Aber da sizeof z.B. bei Speicherreservierung gebraucht wird und statische Member nicht in Objekten gespeichert werden, ... naja du kannst sicher fortsetzen Wo aber sollte man noch sizeof in reinem C++ verwenden? Auch liefert der erste Treffer bei google die Antwort, falls Logik nicht ausreicht.
-
vor allem - mußte man Klassenvariablen unbedingt auch mit 'static' einleiten, wo dieses Wort ja schon in C doppelt belegt ist.
-
u-ser_l schrieb:
vor allem - mußte man Klassenvariablen unbedingt auch mit 'static' einleiten, wo dieses Wort ja schon in C doppelt belegt ist.
ja stimmt, das ist auch doof. man könnte sich doch was mit referenzen bauen, etwa so:
int staticvar = 12; struct test { int &j; test() : j(staticvar) { j++; } };
^^ 'j' verhält sich wie eine C++ klassenvariable, obwohl kein static davor steht, d.h. diese sonderregelung mit 'static' in der klasse usw, wäre garnicht nötig gewesen.
-
Basher schrieb:
u-ser_l schrieb:
vor allem - mußte man Klassenvariablen unbedingt auch mit 'static' einleiten, wo dieses Wort ja schon in C doppelt belegt ist.
ja stimmt, das ist auch doof. man könnte sich doch was mit referenzen bauen, etwa so:
int staticvar = 12; struct test { int &j; test() : j(staticvar) { j++; } };
^^ 'j' verhält sich wie eine C++ klassenvariable, obwohl kein static davor steht, d.h. diese sonderregelung mit 'static' in der klasse usw, wäre garnicht nötig gewesen.
nö.
einfacher wirds doch durch mehr worte, nicht durch weniger. wie willste denn hier begründen, daß sizeof(test)==1?
denn bei
struct test
{
int &j;test() : j(staticvar)
{
j++;
}
test(int& nsv) : j(nsv)
{
j++;
}
};
[/code]
wird sizeof(test)==sizeof(void*) sein.
-
Basher schrieb:
u-ser_l schrieb:
vor allem - mußte man Klassenvariablen unbedingt auch mit 'static' einleiten, wo dieses Wort ja schon in C doppelt belegt ist.
ja stimmt, das ist auch doof. man könnte sich doch was mit referenzen bauen, etwa so:
int staticvar = 12; struct test { int &j; test() : j(staticvar) { j++; } };
^^ 'j' verhält sich wie eine C++ klassenvariable, obwohl kein static davor steht, d.h. diese sonderregelung mit 'static' in der klasse usw, wäre garnicht nötig gewesen.
Ach! Dann kann ich also mit deiner "statischen" Variable problemlos das Folgende schreiben?
int main() { std::cout << test::j << std::endl; return 0; }
Geniale Idee!
Stefan.