Java in C++ programmieren - Programmier- und Designunterschiede



  • .filmor schrieb:

    hustbaer schrieb:

    unabhängig von funktionaler programmierung oder nicht. es sind die pure funktionen die so wertvoll sind, nicht das funktionale paradigma

    ACK
    Man müsste mal fein C++ mit funktional verheiraten. Bzw. eben um "pure" Funktionen erweitern. Und gleich noch um "pure value types" zusätzlich - spricht ja nix dagegen dass eine "pure" Funktion einen "pure UDT" als Ergebnis hat.

    Aber wie will man das machen? Hat ja schon seine Gründe, dass constexpr-Funktionen (das ist ja ziemlich genau das) nur genau ein vergleichsweise trivialer Ausdruck sein dürfen.

    Und welche Gründe wären das?
    Mir fällt auf jeden Fall nix ein was es verhindern würde da mehr zu erlauben.
    Natürlich würden die Compiler entsprechend komplizierter, aber ... das ist mir ja egal so lange ich so einen Compiler nicht schreiben muss 😃



  • Naja, wie willst du Wirkungen im Programm verhindern, wenn beliebige Ausdrücke zugelassen werden? Alles mit Zeigern ist schonmal tabu, Objekte erstellen könnte auch kompliziert werden (eben weil da vermutlich irgendwo in den Untiefen des Codes Zeiger verwendet werden, was man aber nur herausfinden kann, wenn man den gesamten Code sieht). Entsprechendes gilt für andere Funktionen.
    Dann ist natürlich static auch noch nicht möglich und dann bist du schon so weit, dass du eigentlich alles in einen Ausdruck schreiben könntest. Nur Schleifen (bzw. Rekursionen) gingen noch, aber dann sind wir denke ich schon beim Halteproblem. Ich will schon, dass mein Compiler terminiert 😉

    /edit: Hmm, wobei, while-Schleifen sind eh sinnlos und bei for-Schleifen könnte man verbieten, die Laufvariable innerhalb der Schleife zu ändern. Endlosrekursionen abzufangen ist auch möglich. Da geht schon noch was 😉



  • .filmor schrieb:

    Naja, wie willst du Wirkungen im Programm verhindern, wenn beliebige Ausdrücke zugelassen werden? Alles mit Zeigern ist schonmal tabu, Objekte erstellen könnte auch kompliziert werden (eben weil da vermutlich irgendwo in den Untiefen des Codes Zeiger verwendet werden, was man aber nur herausfinden kann, wenn man den gesamten Code sieht). Entsprechendes gilt für andere Funktionen.
    Dann ist natürlich static auch noch nicht möglich und dann bist du schon so weit, dass du eigentlich alles in einen Ausdruck schreiben könntest. Nur Schleifen (bzw. Rekursionen) gingen noch, aber dann sind wir denke ich schon beim Halteproblem. Ich will schon, dass mein Compiler terminiert 😉

    /edit: Hmm, wobei, while-Schleifen sind eh sinnlos und bei for-Schleifen könnte man verbieten, die Laufvariable innerhalb der Schleife zu ändern. Endlosrekursionen abzufangen ist auch möglich. Da geht schon noch was 😉

    Schaut euch doch mal das Buch "Programming Erlang" an, da wird auch genau diese Problematik angesprochen (in den ersten 1 oder 2 Kapitel) und auch immer mal wieder darauf hingewiesen, wenn man an bestimmten Stellen nur auf Built-in Funktionen zugreifen darf um eben genau das garantieren zu können.



  • .filmor schrieb:

    Endlosrekursionen abzufangen ist auch möglich. Da geht schon noch was 😉

    Endlosrekursion abfangen geht im allgemeinen nicht. Normalerweise setzt man einfach ein Limit auf die maximale Rekursionstiefe, aber damit unterbindet man eben auch korrekte, aber sehr tiefe, Rekursion.

    Dass der Compiler nicht immer in akzeptabler Zeit terminiert, ist heute auch schon der Fall bei template meta programming: Das ist turing-complete, im Extremfall (manche Limits außen vor gelassen) ist die Frage, ob ein gegebener C++-Quellcode fehlerhaft ist, also äquivalent zum Halteproblem.



  • Christoph schrieb:

    .filmor schrieb:

    Endlosrekursionen abzufangen ist auch möglich. Da geht schon noch was 😉

    Endlosrekursion abfangen geht im allgemeinen nicht. Normalerweise setzt man einfach ein Limit auf die maximale Rekursionstiefe, aber damit unterbindet man eben auch korrekte, aber sehr tiefe, Rekursion.

    Okay, im Allgemeinen kann man es vielleicht nicht abfangen. Aber Rekursionstiefe könnte man auch per Compilerschalter modifizierbar machen (wie es auch heutezutage bei Templates ist).



  • @.filmor:
    Dass C++ templates bereits turing complete sind wurde ja schon erwähnt, d.h. hier ändert sich nix.

    Das Thema ist sicherlich nicht trivial, aber ich bin überzeugt davon dass es möglich wäre da *wesentlich* mehr zu machen als im neuen Standard vorgesehen ist.



  • Naja, Templates sind aber von sich aus wirkungsfrei (hab mir mal die Freiheit genommen, side effect halbwegs sinnvoll zu übersetzen ;)), normaler C++-Code nicht. Um Turingvollständigkeit geht's ja eigentlich gar nicht, das hab ich vorhin etwas vermischt. (Wobei es natürlich trotzdem ganz angenehm ist, einen deterministischen Compiler zu haben ;))



  • .filmor schrieb:

    Sowas gibt's aber in rein funktionalen Programmen schlichtweg nicht, nicht mal in den kleinsten Einheiten des Programmes.

    Das ist nicht zutreffend. Das IO-Problem funktionaler Programmierung ist genau das Shared Data Problem aus anderen Programmiersprachen. Ohne Shared Data kommt man nun einmal nicht aus.



  • ~john schrieb:

    .filmor schrieb:

    Sowas gibt's aber in rein funktionalen Programmen schlichtweg nicht, nicht mal in den kleinsten Einheiten des Programmes.

    Das ist nicht zutreffend. Das IO-Problem funktionaler Programmierung ist genau das Shared Data Problem aus anderen Programmiersprachen. Ohne Shared Data kommt man nun einmal nicht aus.

    Ich rate dir, mal Haskell anzuschauen. Dort ist das Problem recht geschickt gelöst.
    Im Prinzip gibt es keine IO-Funktionen in Haskell, sondern IO-Objekte, die den shared state auf eine Weise kapseln, dass referentielle Transparenz auf jeder Ebene erhalten bleibt.



  • Christoph schrieb:

    ~john schrieb:

    .filmor schrieb:

    Sowas gibt's aber in rein funktionalen Programmen schlichtweg nicht, nicht mal in den kleinsten Einheiten des Programmes.

    Das ist nicht zutreffend. Das IO-Problem funktionaler Programmierung ist genau das Shared Data Problem aus anderen Programmiersprachen. Ohne Shared Data kommt man nun einmal nicht aus.

    Ich rate dir, mal Haskell anzuschauen. Dort ist das Problem recht geschickt gelöst.
    Im Prinzip gibt es keine IO-Funktionen in Haskell, sondern IO-Objekte, die den shared state auf eine Weise kapseln, dass referentielle Transparenz auf jeder Ebene erhalten bleibt.

    Trifft das auch auf Erlang zu?


Anmelden zum Antworten