Shulou(Shulou.com)06/03 Report--

This article mainly explains "how to use C++ for functional programming", interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Next, let the editor take you to learn "how to use C++ for functional programming"!

Functional programming with C++

Pure function

A pure function is a function that only looks at the parameters passed in, and all it does is return one or more values calculated based on the parameters. It has no logical side effects. This is, of course, just an abstraction; at the CPU level, every function has side effects, and most functions have side effects at the heap level, but this abstraction is still valuable.

The pure function does not view or update the global state, does not maintain the internal state, does not perform any Istroke O operations, and does not change any input parameters. It's best not to pass it any extraneous data-- if you pass an allMyGlobals pointer in, that goal is basically dashed.

Pure functions have many good properties.

Thread safety pure functions that use value parameters are thoroughly thread safe. If you use reference or pointer parameters, even if it is const, you should be aware of the risk that a thread performing impure operations may change or release its data. But even in this case, pure functions can be a powerful tool for writing safe multithreaded code. You can easily replace a pure function with a parallel implementation, or run multiple implementations and compare the results. This makes it easier for code to experiment and evolve.

Reusability it is much easier to migrate a pure function to a new environment. Type definitions and all other pure functions that are called still need to be processed, but there will be no snowball effect. How many times do you know that another system has code to meet your needs, but it's easier to free it from all the assumptions about the system environment than to rewrite it?

Testability Pure functions have reference transparency (referential

Transparency), that is, whenever it is called, it always gives the same result for the same set of parameters, which makes it easier to use than things that are intertwined with other systems. I have never been particularly responsible in writing test code; so much code interacts with so many systems that using them requires quite fine control, and I am often able to convince myself (perhaps incorrectly) that the effort is not worth it. Pure functions are easy to test, and their test code is like an excerpt directly from a textbook: construct some input and view the results. Every time I come across a small piece of code that currently looks like a bit of a trick, I break it down into a separate pure function and write a test. The scary thing is that I often find problems in such code, which means that the test safety net I cast is not big enough.

Understandable and maintainable input and output limitations make pure functions easier to relearn when needed and less likely to hide external information due to lack of documentation.

Automatic reasoning of formal systems and software will become more and more important in the future. Static code analysis is already important today, and converting the code to a more functional style helps tools analyze it, or at least allows faster local tools to cover as many problems as slower and more expensive global tools. Our industry is about "get things done," and I haven't seen the formal proof of the "correctness" of the whole program as a real goal, but it's also valuable to be able to prove that there are no specific kinds of problems in a particular part of the code. We can use more scientific and mathematical achievements in the development process.

Students who are taking an introduction to programming class may scratch their heads and think, "aren't all programs written that way?" The reality is that there are more "Big Balls of Mud" programs and fewer clearly structured programs. Traditional imperative programming languages provide you with security hatches, and as a result they are always used. If you just write some code that can be used and thrown away, it is common to use the global state in a convenient way. If you are writing code that will still be used a year later, balance the convenience of the moment with the inevitable hassle of the future. Most programmers are not good at predicting the pain of changing the code in the future.

"Pure" practice

Not everything can be pure, and unless the program only operates its own code, it always interacts with the outside world at some point. Trying to maximize the purity of your code can be unimaginably fun, but to reach a pragmatic tipping point, we need to acknowledge that side effects are necessary at some point and then manage them effectively.

Even for a particular function, this is not an all-or-nothing goal. As the purity of a function increases, its value can increase continuously, and the value from "almost pure" to "completely pure" is lower than that from "spaghetti state" to "basically pure". As long as you move the function toward a pure goal, you can improve your code, even if you don't achieve full purity. A function that increases or subtracts a global counter or checks for a global debug flag is impure, but if that is its only disadvantage, it can still reap most of the benefits of the function.

Avoiding the worst outcome in a larger context is often more important than achieving perfection in limited situations. Consider the most unpleasant function or system you've ever dealt with, one that can only be dealt with in full arms, and it's almost certain that there must be complex state networks and assumptions on which code behavior depends, and these complexities don't just occur in parameters. Strengthening constraints in these areas, or at least trying to prevent more code from falling into a similar mess, will have a much greater impact than squeezing a few underlying mathematical functions.

Refactoring code towards a pure goal usually involves freeing the computation from the environment in which it runs, which almost certainly means more parameter passing. It seems a little strange-enough hassle has been scolded in programming languages, while functional programming is often associated with reduced code size. Programs written in functional programming languages are more concise than imperative languages, and the factors are largely orthogonal to the use of pure functions. these factors include garbage collection, powerful built-in types, pattern matching, list derivation, function synthesis, and various grammatical sugars. Most of the reduction in program size has nothing to do with functions, and some imperative languages can have the same effect.

If you have to pass more than a dozen parameters to a function, you should be annoyed, and you can ReFactor the code in some ways to reduce the complexity of the parameters. C++ does not have any language support to maintain the purity of functions, which is really not ideal. If someone uses some bad way to make a widely used basic function no longer pure, all code that uses this function will lose its purity. This sounds catastrophic from a formal system point of view, but again, this is not the idea of "all or nothing" that has nothing to do with the Buddha. Unfortunately, the problems in large-scale software development can only be statistical.

It seems that it is necessary to add the keyword "pure" to the future Cmax Cure + language standard. C++ already has a similar keyword const- an optional modifier that allows you to check the programmer's intentions at compile time, plus it's good for the code without harming it. The D language does provide a "pure" keyword: http://www.d-programming-language.org/function.html. Note the distinction between weak purity and strong purity-references or pointers in input parameters need to be modified with const to achieve strong purity.

In some ways, the language keywords are too strict-a function can still be pure even if it calls a non-pure function, as long as the side effects do not escape from the function. If a program only processes command-line arguments and does not operate on random file system states, then the whole program can be regarded as a purely functional unit.

Object-oriented programming

Michael Feathers (twitter @ mfeathers) says that OO makes the code understandable by encapsulating moving parts. FP makes the code understandable by minimizing the number of moving parts.

"moving parts" is the state in the process of changing. Telling an object to change itself is the first lesson in the basic textbook of object-oriented programming, which is deeply ingrained in the minds of most programmers, but it is an anti-functional behavior. The basic OOP idea of organizing functions with the data structures they operate on clearly has its value, but if you want to reap the benefits of functional programming in your own code, you must alienate some object-oriented behavior in those parts of your code.

Class methods that cannot be declared as const are by definition impure because they modify some or all of the state collection of objects, which can be large. They are not thread-safe, poke here, poke there, and put the object into an unexpected state bit by bit, this power is really the inexhaustible source of Bug. Without considering the implicit const this pointer, the const object method can still be considered a pure function from a technical point of view, but many objects are so large that they are large enough to constitute a global state, thus weakening some of the benefits of pure functions in terms of simplicity and clarity. Constructors can also be pure functions, and you should usually try to make them pure functions-- they take parameters and return an object.

From a flexible programming perspective, you can often use objects in a more functional way, but you may need a little interface change. At id Software, we used an idVec3 class for a decade that had only one void Normalize () method that changed itself, but no corresponding idVec3 Normalized () const method. Many string methods are defined in a similar manner, operating on themselves rather than returning a new copy of the operation-- such as ToLowerCase (), StripFileExtension (), and so on.

Performance influence

In any case, directly modifying memory blocks is almost an insurmountable optimal solution, and failure to do so will inevitably sacrifice performance. Most of the time this is only a theoretical benefit, and we always trade performance for productivity.

Using pure functional programming can lead to more data replication, which is clearly an incorrect implementation strategy in some cases for performance reasons. To take an extreme example, you can write a pure function DrawTriangle (), take a framebuffer parameter and return a new frame cache with triangles drawn as a result. Don't do that.

Returning all results by value is a natural functional programming style, but always relying on the compiler to optimize return values can be harmful to performance, so passing reference parameters is often reasonable for complex data structures of function output, but there is a downside: it prevents you from declaring the return value as const to avoid multiple assignments.

Many times people have a strong desire to update a value in an incoming complex structure, rather than making a copy and returning the modified version, but this is tantamount to abandoning thread safety, so don't do it easily. The generation of lists is a reasonable situation in which local updates can be considered. To append new elements to the list, a purely functional approach is to return a new copy of the list containing the new elements at the end, leaving the original list unchanged. Real functional languages use special techniques in implementation so that the consequences of this behavior are not as bad as they sound, but if you do so on a typical C++ container, you are dead.

An important mitigation factor is that today's performance means parallel programming, which requires more replication and merge operations even in the best-performing cases than in a single-threaded environment, so the loss caused by replication is reduced. the benefits of reduced complexity and improved correctness have increased accordingly. For example, when you start thinking about running all the characters in a game world in parallel, you will come to understand that updating objects in an object-oriented way is very difficult in a parallel environment. Maybe all objects refer to a read-only version of the world state, but copy the updated version at the end of a frame. Hey, wait a minute...

How to act

Check some complex functions in your code base and track the external state of each bit it can touch and all possible state updates. Even if you don't make any changes to it, putting this information in a comment block is already excellent documentation. If the function can-for example, trigger a screen refresh through the rendering system, you can raise your hand directly in the air, declaring that all the positive side effects of the function are beyond human understanding. The next task you need to do is to rethink the function from scratch based on the calculation actually performed. Collect all the input, pass it to a pure function, then receive the result and process it accordingly.

When debugging the code, let yourself focus on the updated status and hidden parameters quietly coming on the stage, thus masking the actual action. Modify the code of some utility objects so that the function returns a new copy instead of modifying itself, except for the iterator, and try to add const before each variable you use.

At this point, I believe you have a deeper understanding of "how to use C++ for functional programming". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.