Verleitet C++ zum komplizierteren denken?
-
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.
-
ja, so ist es - OOP sollte eigentlich die Programmierung syntakisch wie semantisch vereinfachen, und tut das auch in vielen Sprachen, aber bei C/C++ liegt der Sonderfall vor, daß Objektprogrammierung im Rahmen einer statisch typisierten Sprache weitgehend nur simuliert wird, was (im Verein mit der C-Kompatibilität) die bekannten syntaktischen Klimmzüge erforderlich macht.
-
u_ser-l schrieb:
ja, so ist es - OOP sollte eigentlich die Programmierung syntakisch wie semantisch vereinfachen, und tut das auch in vielen Sprachen, aber bei C/C++ liegt der Sonderfall vor, daß Objektprogrammierung im Rahmen einer statisch typisierten Sprache weitgehend nur simuliert wird, was (im Verein mit der C-Kompatibilität) die bekannten syntaktischen Klimmzüge erforderlich macht.
Hä??? Das ist ja ein Gemisch aus Prof84 und Fricky, die Sätze praktisch leer, der Restgehalt falsch und noch ein Häubchen C++-Bashing.
Hast Du schonmal was in C/C++ objektprogrammiert? Inwiefern war dabei die Objektprogrammierung simuliert?
-
OO ist in C++ weitgehend ein "namespace feature".
Echte Objektprogrammierung erfordert späte Bindung, damit Objekte in natürlicher Weise zur Laufzeit manipuliert werden können, etwa indem man ihnen zur Laufzeit neue Eigenschaften zufügt oder ihre Klassenzugehörigkeit ändert usw. - eine Objektwelt muß "formbar" bleiben, wogegen C++-Programme nach der Compilierung "auskristallisieren".
-
um das zu verstehen, muß man aber schon mal über den C++-Tellerrand geblickt haben.
-
u_ser-l schrieb:
Echte Objektprogrammierung erfordert späte Bindung
Unfug.
-
u_ser-l schrieb:
Echte Objektprogrammierung erfordert späte Bindung, damit Objekte in natürlicher Weise zur Laufzeit manipuliert werden können, etwa indem man ihnen zur Laufzeit neue Eigenschaften zufügt oder ihre Klassenzugehörigkeit ändert usw. - eine Objektwelt muß "formbar" bleiben, wogegen C++-Programme nach der Compilierung "auskristallisieren".
Nein. Wenn ein Tier heute eine Kuh ist, wird es morgen kein Pferd sein. Und Kühe werden nicht zu wiehern lernen. Diese Phrasen hast Du aus Papers über zum Beispiel self. Klar, es freut einen, wenn man mal einen Mitarbeiter zum Vorgesetzten befördern kann. Helau
.
Das Auskristallisieren hat den Sinn, daß die Schnittstellen fixiert werden, und nicht Chaos und Wildwuchs herrschen. Ich möchte eigentlich nicht, daß die Objekte, die ich in Händen halte, mutieren und auf einmal die ihnen zugedachten Nachrichten nichmal mehr verstehen.
-
volkard schrieb:
Das Auskristallisieren hat den Sinn, daß die Schnittstellen fixiert werden, und nicht Chaos und Wildwuchs herrschen. Ich möchte eigentlich nicht, daß die Objekte, die ich in Händen halte, mutieren und auf einmal die ihnen zugedachten Nachrichten nichmal mehr verstehen.
Was u_ser-l vorschlägt, kann ja durchaus sinnvoll sein. Z.B. könnte ich mir vorstellen, daß ein solches Typsystem für etwa einen C++-Parser recht elegant wäre, der eine Menge Backpatching im AST betreiben muß (in Extremfällen ist er ja erst beim Semikolon in der Lage, ein Statement als Deklaration, Definition oder Anweisung zu erkennen). Aber für die durchschnittliche Real-World-Anwendung ist das natürlich nicht sinnvoll, und eine Voraussetzung für objektorientierte Programmierung ist es keineswegs.
-
C++ ist statisch. Fertig! Das hat nichts mit OOP zu tun. Es gibt auch OOP-Systeme, die ganz ohne Klassen auskommen und eine Art Ducktyping umsetzen. Wenn du das willst, nimm eine andere Sprache. C++ ist nicht dazu gemacht, jeden Scheiss anzubieten.
Typsystem für etwa einen C++-Parser recht elegant wäre
Ein C++Parser muss nicht in C++ geschrieben sein.