I saw a post on the forum today:
"Yes. I first came from the C language. If I had an electronic Foundation, I would like to develop hardware. Now I am working on C #, which is a bit like "tailism ", I don't know why, but I still feel the most calm when writing C ++. In fact, I use "classes" to put functions with similar functions into a class, then, it is not as direct as C functions. At the very beginning, when writing a program, we receive process-oriented thinking. The implementation of object-oriented details is also a process.
Now that this project is almost finished, C, MFC, and C # are all in use. In fact, the heart is really very contradictory. I just want to learn only one language and start from the depth of my soul, I want to write c ++. Every time I write C # in the middle of the night, I will scream, "I want to write c ++, it's just like Mitsui said to coach Anxi, "I want to play basketball", but every time I encounter a problem that C ++ cannot solve in the project, I will miss C #, and conflict. People are the result of conflict. I am the product of C ++ & C"
After reading the above discussion, I think the fundamental problem is not the language. In addition, all problems are rarely attributed to restrictions on language features.
This reminds me of a concept that has always been emphasized in the book code Daquan: programming in a language rather than programming in a language.
The difference between programming in a language is that the idea is limited by the language characteristics. The idea that goes deep into programming in a language is at the top of our thinking, first, we need to determine our ideas and then implement them with language features. Do not limit our thinking to language features.
Whether it's C, C ++, C #, we can write excellent code. The most important factor is your thoughts, your ideas, instead of the language you use.
Example 1:
Assertion refers to the code used during development to allow the program to perform self-check during runtime. Assertions are a powerful tool for excellent programmers. However, some languages do not provide assertions. So we don't have to assert? None! We can easily implement an assertion, for example, in C:
# Define assert (FLAG )/
{/
If (! (FLAG ))/
Printf ("assert failed! File = % s, line = % d./N ", _ file __, _ line __);/
}
Example 2:
An important concept of object-oriented is encapsulation. Generally, when processing global data, the client does not directly access the data itself, but uses the accesser function. For example, if a class has a static variable, it generally has two functions: 1) set *** (); // sets the function; 2) Get ***() // access the function. The advantage of this is: 1) hiding external implementation details. 2) It is easy to expand. If one day the variable will become a struct, the client can basically remain unchanged and only modify the accessors function. 3) There is a central control point to facilitate problem locating.
However, if you use the C language and process-oriented, can you use this method to realize the advantages of encapsulation? The answer is yes. For example, there is a global variable that both files need to access. You can define this file as static and only allow it to be used in the defined file. Then, two non-static accessors are defined for the client to access this global variable. In this way, you can also use the benefits of encapsulation in C.