Warum sollte man C und C++ eigentlich nicht mischen... ?
-
Cya ich geh auf ein Deutschkurs.
-
Zeus schrieb:
Cya ich geh auf ein Deutschkurs.
ich geh*'** auf einen Deutschkurs.*
-
It0101 schrieb:
Warum? Ich finde die Optik von Code nicht ganz unwichtig. Das optische Erscheinungsbild von Code kann die Lesbarkeit durchaus positiv beeinflussen.
Und gerade bei C++ kann Code schön aussehen.Wenn endl für dich schöner ist als \n dann weiss ich echt nicht in welchen Sprachen du programmierst. endl ist ja auch eben NICHT \n.
Ich schreib ja auch nicht einfach immer new Foo() wenn ich ein neues Objekt will weil mir new so gefällt. Die Semantik muss stimmen. Wenn die nicht stimmt, dann bringt dir der optisch schönste Code nichts.
@Shade: Invers mutmaße ich mal, dass dir die Optik von Code egal ist?
Nein, das ist einfach nur dumm.
Aber erstmal muss der Code korrekt sein bevor wir über Schönheit reden können. Es sei denn du nimmst den Anhalter zu ernst, denn dort wird ja gesagt dass Schönheit immer Wahrer ist als die Realität
Warum ich Angst vor deinem Code habe ist folgendes: Wenn du schon bei sowas trivialen die komplett falschen Prioritäten hast (subjektive schönheit über semantischer korrektheit) was kommt dann bei mathematischen Funktionen von dir raus? PI als 7.2 sieht optisch schöner aus? Oder 3 Nachkommastellen sind doof, ich finde 1 schöner?
Semantisch muss es passen - sonst brauchen wir garnicht weiter reden. Und endl ist semantisch falsch. Es erzeugt ein ähnliches Ergebnis wie \n, aber macht etwas komplett anderes.
Wenn du endl so toll findest, dann definiert dir eine konstante endline die \n als Wert hat. Oder schreib dir einen passenden manipulator. Du bist ja nicht gezwungen \n zu schreiben wenn du nicht willst.
Nur erzähl wenigstens dann Anfängern keinen Blödsinn.
-
Aus meiner Sicht ist std::endl semantisch nicht falsch, aber ok...
Wir müssen auch nicht einer Meinung sein.Es gibt einfach Punkte, die nicht entscheidend sind. Und wenn du von einer Angewohnheit bzgl. eines winzigen unwichtigen Details auf meinen kompletten Programmierstil schließt, dann ist dir ohnehin nicht mehr zu helfen...
Ich verlinke hier mal ein Tutorial eines Herrn Namens Volkard
http://www2.fh-augsburg.de/informatik/vorlesungen/XX/c_cplus/tutorial/henkel/Dazu zitiere ich mal aus Lektion 3 die "alles entscheidene Zeile 4":
cout<<"Hello, world!"<<endl;Oh mein Gott, bei allen Heiligen! Also was heutzutage Anfängern beigebracht wird ist wirklich entsetzlich!
Und mit keinem Wort wird dem unbescholtenen Anfänger gegenüber erwähnt, wie böse std::endl ist! Ich bin schockiert... 
-
Ich bin dafür, den Troll nicht weiter zu füttern.
-
It0101 schrieb:
Warum? Ich finde die Optik von Code nicht ganz unwichtig. Das optische Erscheinungsbild von Code kann die Lesbarkeit durchaus positiv beeinflussen.
Und gerade bei C++ kann Code schön aussehen.Aber man muß seinen Geschmack gelegentlich einem Realitätstest unterziehen. Ich schrieb früher auch lieber endl. Aber als dann Dateiausgaben immer anders aussahen als Konsoleausgaben, das war doch Murks.
-
volkard schrieb:
It0101 schrieb:
Warum? Ich finde die Optik von Code nicht ganz unwichtig. Das optische Erscheinungsbild von Code kann die Lesbarkeit durchaus positiv beeinflussen.
Und gerade bei C++ kann Code schön aussehen.Aber man muß seinen Geschmack gelegentlich einem Realitätstest unterziehen. Ich schrieb früher auch lieber endl. Aber als dann Dateiausgaben immer anders aussahen als Konsoleausgaben, das war doch Murks.
Leuchtet mir durchaus ein.
Ist ja nicht so, dass ich unbelehrbar bin.
Nur die Herangehensweise von Shade, dass es genau eine Lösung für eine Aufgabenstellung gibt, und alle anderen falsch sind, kann ich so nicht unterstützen. Aber ich akzeptiere seine Meinung.
-
It0101 schrieb:
Nur die Herangehensweise von Shade, dass es genau eine Lösung für eine Aufgabenstellung gibt, und alle anderen falsch sind, kann ich so nicht unterstützen. Aber ich akzeptiere seine Meinung.
Das hat Shade nicht gesagt und auch nie gemeint!
-
Shade sagt nicht, dass \n das einzig richtige wäre, er sagt, dass endl an der Stelle falsch ist! Und damit hat er Recht! Wenn du Zeilenende meinst, dann mach ein Zeilenende. Wenn du Zeilenende + flush meinst, dann sag endl (oder \n und flush)! Warum sagst du dann endl, wenn du Zeilenende (ohne flush) meinst?
-
Zeus schrieb:
It0101 schrieb:
Nur die Herangehensweise von Shade, dass es genau eine Lösung für eine Aufgabenstellung gibt, und alle anderen falsch sind, kann ich so nicht unterstützen. Aber ich akzeptiere seine Meinung.
Das hat Shade nicht gesagt und auch nie gemeint!
SeppJ schrieb:
Shade sagt nicht, dass \n das einzig richtige wäre, er sagt, dass endl an der Stelle falsch ist! Und damit hat er Recht! Wenn du Zeilenende meinst, dann mach ein Zeilenende. Wenn du Zeilenende + flush meinst, dann sag endl (oder \n und flush)! Warum sagst du dann endl, wenn du Zeilenende (ohne flush) meinst?
Genau das meinte ich weiter oben mit den dogmatischen Auslegungen für Dinge, die nie dogmatisch gemeint waren. Wenn Aussagen nicht haarklein erklärt werden und die Ausnahmen und wenns und abers in ellenlangen Absätzen erklärt werden, kommt immer jemand, der sie aus dem Kontext reißt und als absolute Aussagen mit Anspruch auf allgemeingültigkeit hinstellt, um sie a) so weiterzutragen oder b) dagegen zu wettern. In diesem Fall warst du, It0101 der b)-Fall
-
Also auf jeden Fall ist It0101 ein schlimmer Kontextreißer:
It0101 schrieb:
Zeus schrieb:
Sie ist relativ aber bestimmt nicht zwingend subjektiv.
"nicht zwingend" reicht mir völlig.
-
... womit dann auch die Fragestellung des OP entsprechend zu ändern wäre:
"Warum sollte man C und C++ eigentlich nicht mischen... ohne (guten) Grund?"
Die beantwortet sich damit allerdings von selbst.
-
Nexus schrieb:
Nach "C vs. C++" und "Java-Programmierer müssen nicht denken" braucht dieser Thread sicher nicht auch noch einen "Windows ist doof"-Flamewar
Anscheinend nicht.
Aber wir hatten einen entlarvten Troll
Belli schrieb:
Ich bin dafür, den Troll nicht weiter zu füttern.
und einen Nazivergleich.
It0101 schrieb:
Ach nein ich vergas. C++ ist ja quasi eine Diktatur. Einer legt die Regeln fest und alle anderen müssen genau dieser Meinung sein.
Wer ist in dem Fall eigentlich unser meinungsvorgebender Führer?Das ist doch schon was!
-
Nicht zu vergessen: das Diskussionverbot.
lk schrieb:
Bis 1k views noch, dann erkläre ich diese Diskussion als geschlossen.
-
Eine Vermischung von C/C++ wurde teilweise damit begründet, C++ Code mit C in Bezug auf die Geschwindigkeit zu optimieren.
Wäre da nicht Assembler viel besser für geeignet?
-
Wenn du Lust hast das zu entwickeln, auf alle Plattformen zu portieren und dabei sogar noch besser bist als ein optimierender Compiler, nur zu.
Im übrigen ist dieser Geschwindigkeitsvorteil von C nur in recht spezifischen Situationen gegeben, nämlich da wo die C++-Standardmittel von sich aus Sachen machen die für die Anwendungssituation übertrieben allgemein sind. Ein gutes Beispiel sind die Streams mit ihren ganzen Locales und Formaten gegen die C I/O. In einem Programm welches nur mit US-Englischen Formaten zurechtkommen muss (ziemlich normal) und in dem die Ein-/Ausgabe der Flaschenhals ist (eher ungewöhnlich) kann es sich daher lohnen auf die C-Bibliothek zu setzen. Das meiste andere in der C++-Bibliothek ist eher Abstraktion für Sachen die man in C dauernd von Hand machen müsste und das kostet nichts.
-
redrew99 schrieb:
Eine Vermischung von C/C++ wurde teilweise damit begründet, C++ Code mit C in Bezug auf die Geschwindigkeit zu optimieren.
Wäre da nicht Assembler viel besser für geeignet?
Zeige mir einen Assembler-Programmierer, der auf modernen CPUs mehr herausholt, als der {C/C++}-Compiler, der rattenscharf alle Befehle in die Pipelines so reinsortiert und umsortiert, daß keine unnötigen Lücken entstehen.
Normale Sachen per Hand in ASM sind erbärmlich. ASM ist erst dann gut, wenn man Sachen wie RDTSC oder BSF macht, die {C/C++} nicht bereitstellen. Und dann sollte man diese Befehle als inline-Funktion mit drinnen inline-asm bereitstellen. Damit der Optimierer sogar das fein umsortieren kann. MS sortiert sogar supi locker um, auch über Funktionsgrenzen hinaus und gleichzeizig in die inline-asm-Sequenzen hinein. GCC leider nicht. Da muß man jeden einzelnen Befehl als eigene inline-asm-Sequenz absetzen. Dann kann er er aber auch und sortiert frei herum und macht irgendwas geiles daraus, was man per Hand nur mit vielen Messungen, dem Taschenrechner und ca 10 Minuten pro asm-Befehl schaffen würde.
hihi.
Und daß C++ wegen des Exception-Handlings, das inzwischen zu null Laufzeitkosten geschehen kann, solange keine fliegt, gleichwertigen C-Code plattmacht, habe ich schon woanders bewiesen.
