Verleitet C++ zum komplizierteren denken?
-
Neue These:
Die neueste Entwicklung im
http://www.c-plusplus.net/forum/viewtopic-var-p-is-1746176.html#1746176
sagt mir, daß es daran liegt, daß die Leute die schlechter lesbare Variante einfach so als die bessere ansehen. Nichts mit Imponiergehabe oder Jobsicherung, kein Getrolle, nichtmal Spieltrieb. Einfach nur eine unterbewußte Werteinvertierung, der Ursprung ich mir aber noch nicht erklären kann.
-
+fricky schrieb:
^^das sowas compiled (jedenfalls frisst es der mingw ohne warnung), finde ich doof. ein 'int' ist ja wohl kein 'const C&', wo ist da die typsicherheit?
Ist ja auch Kacke programmiert. Diese Automatikkonvertierung schreibt man natürlich nur rein, wenn sie zu keinen Problemen führt, wie Complex(double d):re(d),im(0){}
Kannst nicht mit schlechtem C++-Code nachweisen, daß C++ schlecht ist.
-
volkard schrieb:
Neue These:
Die neueste Entwicklung im
http://www.c-plusplus.net/forum/viewtopic-var-p-is-1746176.html#1746176
sagt mir, daß es daran liegt, daß die Leute die schlechter lesbare Variante einfach so als die bessere ansehen. ...Einfach nur eine unterbewußte Werteinvertierung, der Ursprung ich mir aber noch nicht erklären kann.das muss aber 'ne ausnahme sein. für gewöhnlich bevorzugt der c++ coder gut lesbare, generische konstrukte, die aber innen drin komplex und akademisch sein müssen (op-überladung lässt grüssen). und die im praktischen einsatz oft seltsames verhalten an den tag legen (das zwar ungewollt, lässt sich aber nicht umgehen).
volkard schrieb:
+fricky schrieb:
^^das sowas compiled (jedenfalls frisst es der mingw ohne warnung), finde ich doof. ein 'int' ist ja wohl kein 'const C&', wo ist da die typsicherheit?
Ist ja auch Kacke programmiert....
Kannst nicht mit schlechtem C++-Code nachweisen, daß C++ schlecht ist.irgendwo muss ich ja ansetzen. das ist wie mit dem 'volatile int*', der zum 'bool' wird. solche heimlichen konvertierungen sind mit typsicherheit unvereinbar. dagegen ist sogar C, das musterbeispiel für typunsicherheit, noch typsicherer.
btw, ein 'for_each' ist doch nix anderes als eine andere schreibweise für eine for-schleife. wieso macht Badestarnds code 4 verschachtelte for-schleifen daraus? nur damit mehr komplexität reinkommt, was zu jeder hochwertigen c++ konstruktion dazugehört?
-
+fricky schrieb:
irgendwo muss ich ja ansetzen.
Ja. Nur schade, dass du dabei immer schlechte Beispiele wählst.
+fricky schrieb:
das ist wie mit dem 'volatile int*', der zum 'bool' wird. solche heimlichen konvertierungen sind mit typsicherheit unvereinbar. dagegen ist sogar C, das musterbeispiel für typunsicherheit, noch typsicherer.
Ach komm, so langsam wird es langweilig. Fallen dir echt keine brauchbaren Beispiele ein?
Wie oft hast du schon auf
std::ostream::operator<<rumgehackt? Und wie oft wurde dir dabei schon gesagt, dass das 1. kein Problem der Sprache, sondern der konkreten Implementierung, und 2. in der Praxis dermassen irrelevant ist, dass diese Konvertierung nicht wirklich ein Problem darstellt?
-
Nexus schrieb:
...in der Praxis dermassen irrelevant ist, dass diese Konvertierung nicht wirklich ein Problem darstellt?
meinst nicht?. wenn nicht, dann bestimmt, weil der c++ coder in der praxis ohnehin mit so vielen problemen konfrontiert wird, dass diese heimtückischen, impliziten konvertierungen ihm so gut wie garnicht auffallen. und zwar so wenig, dass er sogar meint, c++ wäre eine typsichere sprache.
Nexus schrieb:
+fricky schrieb:
irgendwo muss ich ja ansetzen.
Ja. Nur schade, dass du dabei immer schlechte Beispiele wählst.
die reichen doch, das sind einfache dinge, die mir irgendwann mal aufgefallen sind. ich muss doch nicht gleich aus'm c++ fqa oder davon: http://www.fefe.de/c++/c%2B%2B-talk.pdf abschreiben
-
Ad aCTa schrieb:
> Es bringt ihnen selbst etwas, weil sie sich dabei fordern.
Omg, und die sollen sich bei der Softwareherstellung fördern? Das gehört doch in den C++ Kindergarten und in keine Release-Software!!!
> Du kannst also nicht nachvollziehen, dass es tatsächlich Programmierer gibt, die Freude am Experimentieren und Kennenlernen neuer Möglichkeiten haben?
Im Projekt wird herumexperimentiert, es muss so sein. Doch meistens sind die einfachste Möglichkeiten am Ende die, die man im Code finden sollte. "Freude am Experimentieren" und Spielereien sind m.E. in der Software-Herstellung völlig fehl am Platze, in der Software heißt es testen testen testen, was sich bewährt und was performant ist und NICHT, ob C++ sowas kann.
a) Lern erst einmal zitieren, es war mir nur schwer möglich deine Antwort zu finden
b) Du musst zwischen Realität und Ideal unterscheiden. Was du als Kunde willst und was der Programmierer tut, das sind zweierlei Dinge. Es gibt natürlich auch die Gruppe von Programmierern die nie experimentieren, aber beide Gruppen haben etwas gemeinsam: ihre Werke tauchen regelmäßig auf thedailywtf.com auf
-
+fricky schrieb:
die reichen doch, das sind einfache dinge, die mir irgendwann mal aufgefallen sind. ich muss doch nicht gleich aus'm c++ fqa oder davon: http://www.fefe.de/c++/c%2B%2B-talk.pdf abschreiben
Oh mein Gott, dieses PDF ist absolut lächerlich. Deine Argumentation wundert mich nicht mehr, wenn du deine Informationen von solchen Quellen holst.
Wenn ich sowas lese:
• Can’t throw exceptions in destructors, shouldn’t in constructors
• Initializers done in order of declaration of fields in class, not written order
• auto_ptr is useless
• Iterators don’t know anything about the container, can’t detect errors
• For a vector, at() does bounds checking, but operator[] doesn’t1. Ist falsch. Exceptions sind unter anderem praktisch, weil man Konstruktionen abbrechen kann.
2. Hat er schon mal an den Overhead gedacht, den es mit sich bringen würde, für jeden Konstruktor eine eigene Initialisierungsreihenfolge festzulegen?
3. Ist falsch und unbegründet.
4. Ist falsch. Siehe zum Beispiel MSVC++s Checked Iterators.
5. Meine Güte, überlegt sich der Autor auch was? Warum gibt es wohl zwei Funktionen dafür?Almost nobody actually understands the error messages.
You get an error message? You start fudging the code until it compiles.Code leaks resources when someone throws an exception
– Have to provide assignment operator, but fail if someone does a=a;Wenn man nicht fähig ist zu programmieren, sollte man sich nicht über die Programmiersprache aufregen.
Throwing exceptions from con/destructors
• Does not even clean up local variables!Vollkommen daneben. Dass er von RAII gehört hat, erwarte ich gar nicht erst.
Diese Dinge zeigen ja wohl deutlich genug, dass der Autor rein gar keine Ahnung hat. Ziemlich erbärmlich, seine "Kritik".
-
Nexus schrieb:
Deine Argumentation wundert mich nicht mehr, wenn du deine Informationen von solchen Quellen holst.
nö, ich hab' keine quellen. meine lästereien basieren auf eigenen erfahrungen und alles andere hab' ich so von anderen in meiner umgebung mitbekommen (deswegen sind sich auch nicht gerade aktuell, weil hier kaum noch jemand c++ benutzt).
Nexus schrieb:
Diese Dinge zeigen ja wohl deutlich genug, dass der Autor rein gar keine Ahnung hat. Ziemlich erbärmlich, seine "Kritik".
gar keine ahnung kannste nicht sagen. er gehört nicht zu den absoluten cracks, die für jede c++ fallgrube auch gleich den passenden umweg parat haben (so wie du vielleicht). aber jeder c++ anwender kommt irgendwann mal an den punkt, an dem er er z.b. ein delete[] anstelle eines delete hätte verwenden müssen oder der auto_ptr rumzickt. und aus dessen perspektive ist das pdf geschrieben, nicht aus expertensicht.
-
Ist doch schon bekannt, daß Anfänger damit Probleme haben. Aber was solls? Anfänger haben in C dauernd Zugiffe auf Nullzeiger und es ist in C für Anfänger unmöglich, ein Fehlermanagement hinzukriegen. Dauernd vergißt man free, weil es keine Destruktoren gibt und wird zum veralteten Single-Entry-Single-Exit getrieben. Solche "Fehler" von C kann man wohl viele Seiten lang aufschreiben und dann noch ein paar erfundene Fehler rein...
Trotzdem ist es uns zu doof, in jedem Thread über die Unzulänglichkeiten von C abzulästern.
-
volkard schrieb:
Trotzdem ist es uns zu doof, in jedem Thread über die Unzulänglichkeiten von C abzulästern.
hast ja recht. lasst und besser wieder auf die frage konzentrieren, warum manche sprachen zu kompliziertheiten anstiften und andere nicht. gibts eigentlich noch mehr programmiersprachen, bei denen die user zur übertreibung neigen, anstatt die einfachste lösung anzustreben?
ach ja, vielleicht hängts mit der anzahl der möglichkeiten und der menschlichen psyche zusammen. viele sind ja so verdrahtet, dass sie meinen etwas komplexes, teures, glänzendes, wertvolles, gut riechendes usw. sein irgendwie 'besser' als was schlichtes, farbloses, schon in die tage gekommenes...
-
+fricky schrieb:
hast ja recht. lasst und besser wieder auf die frage konzentrieren, warum manche sprachen zu kompliziertheiten anstiften und andere nicht. gibts eigentlich noch mehr programmiersprachen, bei denen die user zur übertreibung neigen, anstatt die einfachste lösung anzustreben?
Klar. Allem voran C.
http://www.ioccc.org/
-
Wie waere es mit Perl: Executable line noise.
-
volkard schrieb:
gilt nicht, die machen es da mit absicht unleserlich. normalerweise programmiert man in C ziemlich straight (sagte ja schon der thread-starter). man muss sich sogar richtig anstrengen, um unnötig verzwicktes zeug in C zu coden. denk doch nur mal an deinen primzahlengenerator von gestern.
-
+fricky schrieb:
volkard schrieb:
gilt nicht, die machen es da mit absicht unleserlich.
Die Existenz und Größe dieses Wettbewerbs und die Qualität der Siegerbeiträge zeigt doch, daß es den C-Proggern außerordentlichen Spaß macht.
-
volkard schrieb:
Klar. Allem voran C.
http://www.ioccc.org/Das gibt es für C++ auch. Ist nur etwas praxisorientierter und nennt sich Boost.
</troll>
-
audacia schrieb:
volkard schrieb:
Klar. Allem voran C.
http://www.ioccc.org/<troll>
Das gibt es für C++ auch. Ist nur etwas praxisorientierter und nennt sich Boost.
</troll>rofl.
-
audacia schrieb:
volkard schrieb:
Klar. Allem voran C.
http://www.ioccc.org/Das gibt es für C++ auch. Ist nur etwas praxisorientierter und nennt sich Boost.
aber nicht nur der code der libraries selbst, auch beim anwenden von boost kommt meistens was raus, das beim IOCCC gut mithalten könnte.
-
+fricky schrieb:
ein 'int' ist ja wohl kein 'const C&', wo ist da die typsicherheit?
Wenn man einen Konversionskonstruktor definiert braucht man sich nicht zu wundern, daß er genau das macht. int läßt sich somit in C konvertieren. Und POD-Typen ungefragt konvertieren macht schon C. Daher wurde für diesen Fall auch kein spezielles Keyword definiert. Mit "explicit" läßt sich das Verhalten ja unterbinden, man hätte es auch genau andersherum lösen können, aber das wäre wohl vielen auch nicht recht gewesen. Man muß es halt lernen wie es definiert wurde, in guter Anfängerliteratur wird das auch passend erklärt.
+fricky schrieb:
ist mir bei irgendwelchen experimenten mit C++ schon mehr als einmal passiert, obwohl ich wirklich sehr selten einen C++ compiler anwerfe.
Da liegt das Problem, du kennst die Sprache nicht wirklich und wunderst dich darüber, daß du nur "Pidgin" zustande bekommst.
-
+fricky schrieb:
gibts eigentlich noch mehr programmiersprachen, bei denen die user zur übertreibung neigen, anstatt die einfachste lösung anzustreben?
ich denke jeder Programmierer mit Grips strebt die einfachste Lösung an.
Nur ist "einfach" hier nicht ganz einfach zu definieren:
Wenn du eine Programmaufgabe lösen sollst, in der z.B. Mischmaschinen mit festem Standort vorkommen, und findest eine raffinierte Lösung mit 30K Zeilen Quellcode unter Ausnutzung diverser C-Freiheiten mit zahlreichen "festverdrahteten" Konstanten, die genau die Spezifikation erfüllt und schnell ist: Prima. Für heute.
Nächstes Jahr kommt der Boss und will aus aktuellen wirtschaftlichen Gründen ein Programm haben, das auf einen erweiterten Anwendungsfall mit LKW-Betonmischern angewendet werden soll.
Was nützt nun eine einfache, aber nicht erweiterbare Lösung ? Nichts. Neuprogrammierung ist angesagt.
Hätte man die erste Aufgabe von Anfang an so gelöst, daß die Datenstrukturen abstrakt formuliert (und damit von Einzelheiten der ersten Aufgabe weitgehend unabhängig) sind, hätte man es wahrscheinlich einfacher - man hätte die Datenstrukturen erweitert oder unter Ausnutzung ihrer Allgemeinheit auf den neuen Anwendungsfall spezialisieren können, was bei gutem OO-Design
nicht viele Auswirkungen auf den Rest des Programms zu haben braucht.Datenkapselung und Abstraktion haben ihren Preis hinsichtlich Kompliziertheit und Syntax, zumindest in C/C++, aber wenn das Ziel wiederverwertbare und allgemein formulierte Software ist, kann so etwas langfristig "einfacher" im Sinne von "effizienter" sein.
-
u_ser-l schrieb:
Datenkapselung und Abstraktion haben ihren Preis hinsichtlich Kompliziertheit und Syntax, zumindest in C/C++, aber wenn das Ziel wiederverwertbare und allgemein formulierte Software ist, kann so etwas langfristig "einfacher" im Sinne von "effizienter" sein.