Wie funktional ist C++11?
-
ipsec schrieb:
Na und? C++ erzwingt funktionale Programmierung nicht. Hier wäre eine funktionale Version von accumulate:
template <class InputIterator, class T> T accumulate ( InputIterator first, InputIterator last, T init ) { return first == last ? init : *first + accumulate(next(first), last, init); }
Also ist C++ funktional, weil in C++ StatementExpr unterstützt ? Ein anderen Sinn seh ich in diesen Beispiel nicht.
btw ich finds intressent dass die Leute sagen, C++ ist funktional dies anhand sehr konkreten Stellen machen während die es nicht, nur eine Leitsatz zu hand haben um dies zu entscheiden.
-
Zeus schrieb:
ipsec schrieb:
Na und? C++ erzwingt funktionale Programmierung nicht. Hier wäre eine funktionale Version von accumulate:
template <class InputIterator, class T> T accumulate ( InputIterator first, InputIterator last, T init ) { return first == last ? init : *first + accumulate(next(first), last, init); }
Also ist C++ funktional, weil in C++ StatementExpr unterstützt ? Ein anderen Sinn seh ich in diesen Beispiel nicht.
btw ich finds intressent dass die Leute sagen, C++ ist funktional dies anhand sehr konkreten Stellen machen während die es nicht, nur eine Leitsatz zu hand haben um dies zu entscheiden.
Der Sinn des Beispiels: nur weil auf c-plusplus.com/reference eine imperative Implementierung von accumulate steht, heißt das keineswegs, dass man es nicht auch funktional implementeiren kann.
Hast du irgendeinen Algorithmus, der in C++ nicht funktional zu implementieren geht?
-
ipsec schrieb:
Hast du irgendeinen Algorithmus, der in C++ nicht funktional zu implementieren geht?
Du weiß ganz genau, dass wegen den nicht obligatorischen Tail-Recursion Optimierung die einfachsten mathematische Funktionen nicht portable genug sind um sie funktional implementiert bereitzustellen.
-
Zeus schrieb:
ipsec schrieb:
Hast du irgendeinen Algorithmus, der in C++ nicht funktional zu implementieren geht?
Du weiß ganz genau, dass wegen den nicht obligatorischen Tail-Recursion Optimierung die einfachsten mathematische Funktionen nicht portable genug sind um sie funktional implementiert bereitzustellen.
Damit ist nur gesagt, dass es nicht sinnvoll ist, in C++ funktional zu programmieren (dem stimme ich auch zu), aber nicht, dass es nicht ginge.
-
ipsec schrieb:
Zeus schrieb:
ipsec schrieb:
Hast du irgendeinen Algorithmus, der in C++ nicht funktional zu implementieren geht?
Du weiß ganz genau, dass wegen den nicht obligatorischen Tail-Recursion Optimierung die einfachsten mathematische Funktionen nicht portable genug sind um sie funktional implementiert bereitzustellen.
Damit ist nur gesagt, dass es nicht sinnvoll ist, in C++ funktional zu programmieren (dem stimme ich auch zu), aber nicht, dass es nicht ginge.
Damit werden wir nie Grün, weil das Paradigma ein Leitgedanke ist, dass du nicht anhand von detailierten Kleinkram festmachen kannst.
-
Zeus schrieb:
btw ich finds intressent dass die Leute sagen, C++ ist funktional dies anhand sehr konkreten Stellen machen während die es nicht, nur eine Leitsatz zu hand haben um dies zu entscheiden.
Du findest meine Argumentation schlecht? Was sollte ich denn verbessern?
Angenommen Closures und Funktionen hoeherer Ordnung sind einziges Kriterium. In C++ sind Closures und Funktionen hoeherer Ordnung im Vergleich zu funktionalen Sprachen sehr, sehr beschraenkt. Also unterstuetzt C++ das funktionale Programmierparadigma sehr, sehr beschraenkt.
heißt das keineswegs, dass man es nicht auch funktional implementeiren kann
Aber darum geht es nicht. Es geht nicht darum was so alles moeglich ist, sondern in wiefern mich die Sprache unterstuetzt. Was also wirklich gemacht wird. Schauen wir uns doch mal die STL an. Alle Datenstrukturen sind mit Seiteneffekten behaftet.
avoids mutable state/data
? Selbst dasMinibeispiel
accumulate macht Schwierigkeiten. Um funktional zu sein, muss ich in C++ ziemlich viel ignorieren/wegschmeissen und neu implementieren. Klar ist das moeglich, aber das nennst du Unterstuetzung? Quatsch!dass es nicht sinnvoll ist, in C++ funktional zu programmieren
Genau deswegen unterstuetzt C++ nicht das funktionale Programmierparadigma.
-
knivil schrieb:
Angenommen Closures und Funktionen hoeherer Ordnung sind einziges Kriterium. In C++ sind Closures und Funktionen hoeherer Ordnung im Vergleich zu funktionalen Sprachen sehr, sehr beschraenkt. Also unterstuetzt C++ das funktionale Programmierparadigma sehr, sehr beschraenkt.
Das ist ja schonmal besser als "gar nicht"
Um funktional zu sein, muss ich in C++ ziemlich viel ignorieren/wegschmeissen und neu implementieren.
Oder vom funktionalen Paradigma Dinge weglassen.
-
knivil schrieb:
Zeus schrieb:
btw ich finds intressent dass die Leute sagen, C++ ist funktional dies anhand sehr konkreten Stellen machen während die es nicht, nur eine Leitsatz zu hand haben um dies zu entscheiden.
Du findest meine Argumentation schlecht? Was sollte ich denn verbessern?
Eigentlich dachte wir sind im selben Boot.
-
Zeus schrieb:
Eigentlich dachte wir sind im selben Boot.
Dachte ich auch!
-
Zeus schrieb:
ipsec schrieb:
Hast du irgendeinen Algorithmus, der in C++ nicht funktional zu implementieren geht?
Du weiß ganz genau, dass wegen den nicht obligatorischen Tail-Recursion Optimierung die einfachsten mathematische Funktionen nicht portable genug sind um sie funktional implementiert bereitzustellen.
Tail Call Optimization ist ein Compiler Problem, kein Sprachproblem.
http://drdobbs.com/184401756Moderne Compiler koennen teilweise Tail Call Optimization. Es ist in C++ halt ein komplexes Thema und bringt nahezu nie etwas, deshalb wird es nicht mit aller Kraft verfolgt.
Beispiel:
int add(int a, int b) { if (b == 0) return a; return add(1 + a, b - 1); }
Das macht mein VC++ zu
PUBLIC _add ; Function compile flags: /Ogtpy ; File d:\code\tailrecursiontest\tailrecursiontest\main.c _TEXT SEGMENT _a$ = 8 ; size = 4 _b$ = 12 ; size = 4 _add PROC ; 24 : if (b == 0) ; 25 : return a; ; 26 : return add(1 + a, b - 1); mov eax, DWORD PTR _a$[esp-4] mov ecx, DWORD PTR _b$[esp-4] inc eax dec ecx je SHORT $LN8@add mov DWORD PTR _b$[esp-4], ecx mov DWORD PTR _a$[esp-4], eax jmp _add $LN8@add: ; 27 : } ret 0
Also ist C++ jetzt funktional weil wir Tail Call Optimzation haben?
-
int add(int a, int b) { if (b == 0) return a; return add(1 + a, b - 1); }
macht gcc 4.5 (mingw) mit -O3 -march=native auf AMD Sempron 3000+ zu
pushl %ebp movl %esp, %ebp movl 8(%ebp), %eax addl 12(%ebp), %eax leave ret
Also ist C++ funktional.
-
wer beid en gcc entwicklern hat denn denkzeit darauf verschwendet, SOWAS bis zum letzten Takt zu optimieren? wtf?
-
Der Optimizer von GCC macht mir Angst