Source: I have forgotten it for a long time
People often hear about object-oriented programming. In the past, when I was in school, I also started the object-oriented programming course. Unfortunately, these are all based on C ++ and even VC ++. Unfortunately, I have been a C user for many years. At school, I mainly work on the hardware driver layer and the underlying function layer. After work, I am working on software development on mobile phones. All these are inseparable from C. Although I have to say that C ++ is a good language, its compilation speed, code efficiency, and size limit its embedded application. (But the embedded CPU is getting faster and faster, and the memory capacity is getting bigger. I think using C ++ should be fine. This seems to me the limitation of the embedded compiler. Although both philip and Ti have C ++ compilers, it seems that no one uses this. Is it too expensive? However, in embedded applications, the general use of C language is certain.) Can the C language generated in the process-oriented era use object-oriented thinking? In my opinion, yes. c ++ only adds support for objects at the language level and provides a wide range of object libraries. In C language, we had to be self-reliant. 1. The purpose of Object-oriented thinking is frame-based. The means are abstract. I believe many people understand what Object-oriented thinking is about: Class, abstract class, inheritance, and polymorphism. But why did these concepts emerge? For example, if you buy a monitor, but the Brand Style of the monitor is diverse, what happens when you buy it is unpredictable. How can we describe such a thing in programming languages. The idea of object-oriented is to solve such problems. Writing a program (or even a project) is more difficult, from being available to being rich. Object-oriented language converts various behaviors of programs into objects, and uses Abstract methods to classify (abstract) these objects ), this simplifies complicated things into several main organic combinations (frameworks ). In fact, a lot of things around us are like this: for example, a computer is composed of a motherboard, a CPU, and various cards. This is a framework. While ignoring the differences between different CPUs, different mainboards, different sound cards, NICS, and video cards is abstract. For example, the current education network is composed of the main core nodes: Tsinghua, Peking University, beiyou, and other nodes, and then each subnode forms the entire education network in turn. Therefore, I think the object-oriented programming philosophy is: a large project is structured hierarchically, and each layer is connected by an abstract structure as a whole (Framework-based ), abstract structures are independent of each other and can be independently evolved (inherited and polymorphism ). There is a unified communication mode between layers and between structures (usually the message and event mechanism ). 2. Since the birth of the "Object-Oriented" method commonly used in C language programming, people have come up with many ways to embody the idea of "Object-Oriented. The methods I know are described below. Let's talk about something that everyone is familiar. Haha 1. macro definition:
Some may wonder how the definition of macro came here. Let's take a look at a simple example:
# Define macrofunction afunction
Then you call a lot of afunction in the program, but one day, you suddenly find that you have to use bfunction. (However, afunction cannot be avoided. It is very likely that you will call it later ), in this case, you can # define macrofunction bfunction to achieve this purpose.
Of course, the solution is too simple, sometime na? The funny question is that if I want to change to bfunction, what should I do if I do not change to half? Then we have to find and replace it. 2. The number of static entry functions is the same, and the sub-functions are called using the flag bit:
There are many such typical applications. For example, the NIC Driver has an entry function nilan (INT functioncode, para *). The specific parameters are unclear. However, the nilan subject is as follows:
Long nilan (INT functioncode, para *) {Switch (functioncode) {Case sendpacket: Send (....) Case when epacket: receive (...) .....} Everyone understands what it means. Ensure that the same function name is: The NIC Driver is connected to the PNA + protocol stack. How can we ensure that the PNA + protocol stack and different drivers are compatible, A simple method is to use only one entry function. Call internal functions by changing the parameter values of a function. This method can be evolved: If you want to call a new function in the future, you just need to add the corresponding function parameter value. If we think of the NIC driver and the PNA + protocol stack as two layers, we can find that the interconnection interfaces between layers are very small (here is an entry function ), it is generally a name resolution method rather than a specific function call (using functioncode to call a function, nilan only implements the name resolution function )――! Interface restrictions and name resolution interface restrictions: only a limited number of function name resolutions are known between the layer and the layer: the layer and the layer establish a common correspondence between the name and function, and call the function by name. 3. callback function. I think this is a C-language innovation. Although it is very simple, it is just like how to put up the eggs, but if you did not expect it, hey. If the static entry function implements a manageable macro, callback implements an evolutionary micro-level: it enables a function to be added without recompilation! However, in the earliest days, many people were opposed because it used function pointers. Although the function pointer is flexible, it can only be called to the function twice because it needs to access the memory. The first time it accesses the function pointer, the second time is the real function call. It is not as efficient as a common function. However, in a less demanding environment, function calling itself is not very time-consuming, and the performance of function pointers is not particularly bad. Using function pointers is actually the best choice. However, apart from the performance, the most troublesome part of function pointers is that the program is "broken down ". Imagine: When you read a function pointer in a program, it would be really bad if you don't know which function the Pointer Points. (You can refer to the following articles and use an advanced program framework to avoid this situation.) 3. Read the above descriptions about event and message, I believe that everyone understands why event and message are used. The specific function call will bring a lot of problems (although efficiency is a good practice ). To improve program flexibility, the event and message methods are generated. Replace the common function call with the name resolution method. In this way, if the two parties have the same resolution, they can achieve a unification. However, the role of event and message is more than just that. The event and message functions to establish inter-process communication. The process sends its own message to the control center (simply a message queue, and a while loop continuously retrieves and executes the Message Queue content), and the control program obtains the message, distribute the message to the corresponding process so that other processes can obtain the message and respond to it. Event and message are flexible, because you can add or close a process at any time (you only need to add a list of sent messages) in terms of program implementation, event and message are the same, but they have different concepts. Most events are used for an action, such as what happens to the hardware and what functions need to be called. Message is usually used as an indicator, such as the program or operation command. 4. In fact, the compilation procedure is the same as writing an article. There is an outline first, and then it is gradually enriched. First abstract the skeleton of the program, and then consider other aspects: What happens when the program is extreme? The functions of this part of the program are not yet complete. What problems will it have to be solved in the future? Can programs be expanded? This series of articles is some of my experiences in these stages. I hope to share with you and learn more. Liyuming1978@163.com (this mailbox used to send an article C optimization of the road, now almost into a junk mailbox, huh, the power of the network is really powerful)
