C ++ functional programming (2) Pure Functions

Original article: http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/

Author: John Carmack

-Pan Hong

-March January 2013

-Email:
Popyy@netease.com

-Weibo.com/panhong101

Pure function has only one channel to exchange data with the outside world-parameters and return values. Logically, it has no side effect (the side effect is to exchange data with the external environment of the function)-This is of course only an abstraction. In reality, all functions have side effects at the CPU level, and most functions have side effects at the heap level. Even with these side effects, this abstraction at the logic level is also meaningful.

Pure functions do not read or write global variables. They are stateless and IO-free and do not change any input parameters. Ideally, no external data will be passed in to him, because once a pointer such as allmyglobals is passed in, the above rules will be broken.

Pure functions have many great features.

Thread security. Only pure functions that pass value parameters are completely thread-safe. If there are referenced or pointer-type parameters, even for the const type, you must note that the other thread that will execute the non-Pure operation may change or release these references or pointers, this is dangerous. However, even in this case, pure functions are still a powerful tool to safely Write multi-threaded programs.

You can easily apply Pure functions to parallel computing, or perform multiple computations and then compare the results. This method makes it easier to test and expand the system.

Reusability. It is easy to transplant a pure function to a new runtime environment. You may still need to modify the type definition and these called pure functions, but this will not cause a snowball effect. This effect is often manifested in: many times, you need to use some of your previous code in another system, so you have to extract the code from the original system, then they are integrated into the new system, but at this time you find that it is still troublesome to extract the proportion of the Code.

Testability. Pure functions have reference transparency (referential transparency ). That is to say, for the same input value, it must produce the same output value, but it has nothing to do with when to execute the function. Compared with pure functions, other coupling mechanisms are inferior in terms of test operability. In addition, I have never been very responsible for writing test code-the one that has run on enough systems and has been carefully tested. In addition, I often comfort myself (I am wrong): This test is not necessary. However, pure functions are easy to test, as described in the Tutorial: arrange some input and observe the output. Now, whenever I encounter code that looks complicated, I will strip them out and put them into a separate pure function, and write some use cases to test them. What scares me is that the Code often detects problems, and I really don't think well enough.

Comprehensibility and maintainability. The limitation of pure functions on input and output values makes it easy for programmers who have not been in touch with and are unfamiliar with them for a long time to look back and understand them again when needed. In addition, some requirements related to the external state of the program that are not documented have been eliminated by pure functions.

Formal systems and automatic reasoning software will become more and more important in the future. Static code analysis (static code analysis) is now very important, it will convert the program into a more mathematical Auxiliary analysis tool, or, at least can replace low-speed and expensive global testing tools with quick local testing tools, and maintain the same test coverage. We are in a "task-oriented" industry. We do not have the luxury of aiming at "all programs are correct". It can prove that the key part of our code library is okay, at present, it is more practical. In the development process, we can use more scientific and rigorous methods.

In the face of a newbie-level program example, someone may cut his head and say, "Is that true for all programs ?". The reality is often like this: There are a lot of "Big Balls of mud ). Traditional programming languages give developers a variety of good syntaxes, and everyone's attitude is to use them. If you think that the code you write is "one-time", you may use a large number of global variables. However, if you want your code to be usable after one year, you can weigh it. Your convenience may become a pain point in the future. Most developers are not very good at predicting the pain of code integration caused by code modifications in the future.