Modern Languages directly combine existing modules as they can be close to Lego blocks.ModularLanguage-level support. I think this is gradually realized in the software engineering field.CThe language is too old. Its later generation Go provides two new keywords: import and package.
This is also my most recognized method. The solution mentioned earlier can only be a poor simulation of it. Confirm language-level support, and I am afraid this step can only be done.
In the project practice, I have been USING the USING solution for many years. There have been more complicated and "exquisite" methods before, and they have all been eliminated. Why? Every time a new concept is introduced, the learning cost of new Members is increased. Almost everyone has C-language experience, but their project background is different. There is a cost to accept new things. Anything that is not a "must" at the language level is debatable. There are always details under question. Why not? Maybe it will be better? This is a question that every programmer has said or buried in his heart.
The USING solution is far from perfect. It is just concise enough to be barely accepted by programmers. But it is not concise enough. Because logically speaking, it is redundant. One module uses another module, and the code is self-evident. In the practice of C language, as long as # include a related. h file, it proves that it needs to use the associated module.
The macro-based technique is difficult to solve the correct module initialization order by using # include only once. Because C language does not have obvious module concepts. If every sub-module is compiled as a dynamic library, it may solve the problem. I have tried this solution), but it may lead to other problems. Fine-grained dynamic libraries have too many limitations.
In the past two days, I have carefully considered this issue based on my experience in learning the Go language over the past six months. Think of another solution.
If we can standardize the naming rules of the system's sub-module API, we may be able to use the compiler and related tools to do some meta programming work.
We can use objdump to analyze the compiled. o file. For example, a module foo is implemented in foo. c. Objdump-t can be used to obtain the referenced and exported symbols in. o.
We require that the C APIs in all sub-modules comply with consistent naming rules. If the sub-modules are named with pig, the APIs in the foo module will look like fooApi. The results of objdump can easily identify other submodules referenced in the specification. Then generate an initialization function that can be called similar to the previously mentioned USING method. The custom module initialization function can be uniformly named as fooInit. When this initialization function exists, you can call the automatically generated code.
The entire process may be complicated, but it is easy to automate it using build tools such as make. I will not list the specific implementation. We may soon start an open-source project.
Link: http://blog.codingnow.com/2011/04/module_initialization.html#more