Verleitet C++ zum komplizierteren denken?

volkard

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.

*john 0

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

volkard

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.

audacia

u_ser-l schrieb:

Echte Objektprogrammierung erfordert späte Bindung

Unfug.

volkard

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.

audacia

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.

knivil

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.

ihr seid doch alle in der falschen zonentaxonomie oO mit anti-scoping fällt das komplizierte denken automatisch weg

volkard schrieb:

Nein. Wenn ein Tier heute eine Kuh ist, wird es morgen kein Pferd sein. Und Kühe werden nicht zu wiehern lernen.

das ist die statische Sichtweise. Die dynamische Sichtweise wäre, daß es sinnvoll ist, jetzt einen Stein und später einen Schlüssel in die selbe Hand zu nehmen, ohne dafür eine zweite Hand zu brauchen, weil der Typ "Hand" nur entweder zum Typ "Stein" oder nur zum Typ "Schlüssel" paßt.

Ich unterscheide übrigens zwischen "Objektprogrammierung" und OOP - ersteres liegt für Sprachen wie C++ ohnehin in unerreichbarer Ferne, zweiteres ist erreichbar, wenn auch nicht in dem Sinne, den die Erfinder von OOP im Sinn hatten.

volkard schrieb:

Diese Phrasen hast Du aus Papers über zum Beispiel self.

Lesen bildet. Das Auge sieht mit

volkard

u_ser-l schrieb:

das ist die statische Sichtweise. Die dynamische Sichtweise wäre, daß es sinnvoll ist, jetzt einen Stein und später einen Schlüssel in die selbe Hand zu nehmen, ohne dafür eine zweite Hand zu brauchen, weil der Typ "Hand" nur entweder zum Typ "Stein" oder nur zum Typ "Schlüssel" paßt.

Dumme Hand das. Der Witz an der Objektprogrammierung ist doch, daß man die Welt versucht abzubilden. Also Hände, die mal einen Stein und mal einen Schlüssel halten können. Wenn Du eine NurSteinHalteHand anschraubst und um einen Schlüssel zu halten (statische Sicht) diese ablegst und eine NurSchlüsselHalteHand anlegst oder (dynamische Sicht) sie in eine NurSchlüsselHalteHand transformierst, dann ist das ein großer Designfehler.

audacia

knivil schrieb:

Typsystem für etwa einen C++-Parser recht elegant wäre

Ein C++Parser muss nicht in C++ geschrieben sein.

Ja, und? Behaupte ich das?

u-ser_l schrieb:

Die dynamische Sichtweise wäre, daß es sinnvoll ist, jetzt einen Stein und später einen Schlüssel in die selbe Hand zu nehmen, ohne dafür eine zweite Hand zu brauchen, weil der Typ "Hand" nur entweder zum Typ "Stein" oder nur zum Typ "Schlüssel" paßt.

Suboptimales Beispiel.

interface IPalpable
{
    void foo (void);
};
class Stone implements IPalpable { ... };
class Key implements IPalpable { ... };

Wenn dir explizite Interfaces nicht passen, kannst du in C++ mittels Templates auch implizite Interfaces benutzen.

template <typename T>
    class PalpableObject : public IPalpable
{
    T* obj;
    PalpableObject (T* _obj) : obj (_obj) {}
    void foo (void) { obj->foo (); }
};
class Stone
{
    void foo (void);
};

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.

und weil die sprache auf C aufbaut, haben sich horden von ehemaligen C-programmierern draufgestürzt, weil sie annnahmen, C++ wäre die lösung aller C-probleme und erlöse sie aus der verdammnis der maschinennahen programmierung. im gleichen atemzug wurde alles C-artige für veraltet, unheilvoll und ruchlos erklärt. erst nach vielen jahren stellten sie erschrocken fest, dass sie vor lauter blauäugigkeit aus dem limbus in die wahre hölle hinabgestiegen sind.

volkard

u_ser-l schrieb:

Ich unterscheide übrigens zwischen "Objektprogrammierung" und OOP - ersteres liegt für Sprachen wie C++ ohnehin in unerreichbarer Ferne, zweiteres ist erreichbar, wenn auch nicht in dem Sinne, den die Erfinder von OOP im Sinn hatten.

Du schaffst Dir eine Privatsprache und nimmst sie als Diskussionsgrundlage. Quizfrage: Von welcher bekannten Leaderpersönlichkeit in diesem Forum kennen wir das?

u_ser-l schrieb:

volkard schrieb:

Diese Phrasen hast Du aus Papers über zum Beispiel self.

Lesen bildet. Das Auge sieht mit

Was willst Du damit ausdrücken?

knivil

Also dein Beispiel mit Hand, Stein und Schluessel ist sehr vage. Ueber Ableitung von Gegenstand kann ich sowohl Schluessel, Stein (als auch Hand) in der Hand halten, ohne neue Handklassen zu benoetigen.

Ich unterscheide übrigens zwischen "Objektprogrammierung" und OOP - ersteres liegt für Sprachen wie C++ ohnehin in unerreichbarer Ferne, zweiteres ist erreichbar, wenn auch nicht in dem Sinne, den die Erfinder von OOP im Sinn hatten.

Du willst mir jetzt sagen, was der Erfinder von C++ sich gedacht hat aber dennoch nicht erreicht hat? Und dann sowas wie OOP in C++ produziert hat? So in der Art: was will mir der Autor damit sagen? Nein, C++ wollte garantiert nicht sowas wie Smalltalk oder CLOS als OOP-System. Performance ist ein wichtiges Kriterium, das durch diese Konzepte gefaehrtet wuerde. Auch hat das nichts mit C++ zu tun, sondern trifft auf alle Sprachen wie Java, C, ... zu. Deine Argumentation ist Bullshit.

So what's your point?