Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
Functional Programming in C++: Why?
On and off I will read an article about functional programming as a supposedly ultra useful paradigm in programming. So naturally I would be interested in using this with C++. I have used some forms of functional programming in Python and it seems useful in some cases. However, I have not seen a real use for it in my day to day C++ code. Every article I have read usually shows how to write generic functions (which can be reused), but it is usually coupled with code that calls a function for each element of a container. This seems wasteful to call a function so many times when a decent loop can do the same thing. Yes, I get the idea of reducing errors by not using local variables as intrinsic to the style. Yet the performance hit would seem to be huge with lots and lots of function calls.
So is that the trade-off with functional programming in C++? Very generic code (high reuseability) vs massive amounts of function calls. Does the compiler just treat these calls like a jump for a lambda? Or is it actually stuffing things onto and off the stack for each call? If it is a paradigm shift, I am just not seeing the value of the paradigm.
Also, according to people who know, C++ now has most of the things required to do functional programming.
Ivan Čukić's book: Functional Programming in C++ has pretty good explanation about the rational behind.
These 2 videos on youtube helped a bit as well. That book looks very interesting.
So is that the trade-off with functional programming in C++? Very generic code (high reuseability) vs massive amounts of function calls. Does the compiler just treat these calls like a jump for a lambda?
Not really no. If you're using inline functors (e.g. templates or function objects that are inlined) the compiler's going to optimize the living daylights out of any function calls. In the end you're going to end up with no
calls in the assembly.
Lambdas are not functions. Ideologically they're objects, but in practice the compiler inlines every last piece of them, so their bodies end up directly in code, as if they never existed.
If it is a paradigm shift, I am just not seeing the value of the paradigm.
There's some value in some places. For example Eigen uses expression templates to lazy evaluate the matrix/vector operations it does. As usual it's a tool, which is transforming to a fad in recent times. Best advice: use it when it makes sense, don't when it doesn't.
I have been paying attention to areas that might benefit from functional programming. I found that lambdas and std::bind can reduce complexity for button callbacks connected by signal. Both the lambda and std::bind return an object that can contain state. This was really useful in replacing QSignalMapper in some of my code.
I also found a use for std::bind (could be a lambda as well) could return an object that was added to a vector. This was used to apply game rules with embedded parameters. The parameters were used for the rule check. This was a neat solution. So I am starting to see how functional approaches can reduce complexity in some areas. I did find that the functional approach could constrain the solution though. So for the rule check I ended up with a more data centric approach. There was not a whole lot gained embedded the rule parameters in the end for that specific case. However, I am starting to see how it could be very useful when coupled with a oop/structured/layered approach.
I have been taking special note of functions with side effects. I just cannot seem to avoid the side effects of certain functions. In an object approach one function may set many different parameters inside itself. So it seems at times that functional programming is inverse to oop functions inside the class itself. Class functions tend to set all sorts of things. Not sure if the two paradigms are compatible in the extremes.
I plan on getting the book @SGaist mentioned, but in the meantime I finally found a FP explanation. I like this because it uses Python to describe the concepts and not some FP specific language I don't know. I think this can be important when coming from predominately imperative languages. I don't want to program in FP style, but I want to expand my toolbox for the programming languages I already use. I learned a great deal programming in Python and now am learning even more coming back to C++ full time. I unknowingly started learning a lot of the FP concepts Python offers and now am seeing parity in C++ features.
So, anyway, here is the article: https://maryrosecook.com/blog/post/a-practical-introduction-to-functional-programming
I have this book. I have read chapter 1. I was on the fence as to the value of FP. The first chapter definitely has concrete and relatable examples of how the FP approach can improve my code. It does not espouse the idea of only using FP, but a more pragmatic approach of balancing how you think about code. I like the idea of adding tools to my toolbox rather than upending how I write code altogether. The best way to describe the approach this book is taking so far is: thinking about the process versus thinking about the steps. It is very similar to process control in that respect. So its a refreshing way to model code. I expect good things in the next chapters.