Conditional compilation in Source Insight

Conditional compilation is a major feature of C language. In engineering based on C implementations, version control, platform porting, and debug output are largely implemented by conditional compilation.

But multi-layered nesting of complex conditional compilations is difficult for code analysis, especially in the face of large-scale code groups. As far as the current work is concerned, this situation is rarely seen in the GUI section, because the GUI part of the program changes greatly, the logic is relatively simple. If you have seen the Winmgr program, you will find that there are several sets of conditional compilation switches within a function, and these switches are mostly related to versioning, and the lack of corresponding documentation, we do not understand these switches, to understand the difficulties.

Before, my processing mode is artificial manual simulation preprocessor switch lifting, time-consuming and laborious. Have to admit that Source Insight (SI) has done what all programmers want. The following describes the conditional parsing function in Si--edit Conditions. If you have already understood, please inform, I humbly consult with you, if also suffered, hope to be helpful to you.

Source Insight divides the compilation switches (hereinafter referred to as Conditions) into two categories: Global (Global Conditions--g Class) and engineering-related (project specific CONDITIONS--PS classes). The so-called G class, the scope is all SI engineering documents; that is, once a condition is set to G, the condition is included for conditional resolution when a new project is completed with a full engineering resolution (build or Rebuild). PS class is that these conditions are only valid for the current project.

In principle, it is suitable for PS-class analysis of RD-DVD engineering, because the RD-DVD changes in each period are very small, especially the bottom layer. For example, the values for each version of the build condition may be different for the following:
MODX2
Modx2_help
MODX3
Modx3_net
Modx3_patch

But it involves a problem of ease of operation. Since SI does not provide a file operation similar to import and export, the conditions collection between independent SI projects cannot be shared quickly, so if you set the conditions collection manually for each SI project, it is bound to be more cumbersome. For this reason, the G class conditions setting is recommended.

Class G: Language tab, Preferences, Top-level menu options, Global Conditions, manually add each condition, set true or False or a specific value ; Click OK to save.

PS class: Top-level menu options-Preferences-language tab, Project specific Conditions, set as before.

Note the point:
1. Since the G class is global, it is possible to re-set the conditions when new works are replaced;
2. After adding a new conditions, for "rebuild" prompt, select "No" is to achieve real-time resolution updates, if it is not real-time resolution, then you can only choose "Yes."
3. Context-sensitive shortcut menu--edit condition can also implement conditions settings.
The 4..cf3 file is a configuration file for Si and can be shared using the options---Load configuration command for Class G conditions.

Edit Condition

A lot of code, especially driver code, has a lot of precompiled definitions to support different hardware configurations. The most painful thing to do when reading such code is that it is not easy to judge the code branching that the program actually executes. A large number of branches exist at the same time, often confusing our audiovisual. For example, the following code:

#ifdef DEV1
/* DEV1 Code code */
#else
/* Other Device execution code */
#endif

If you are sure that we are currently analyzing the execution of DEV1, then you can select DEV1 and then right-click the edit Condition option in the pop-up menu and set the parsing value to true in the pop-up conditional DEV1 window #ifdef DEV1 is equivalent to # if 1, which is quite commented out the code of the #else branch (the color will be dimmed). Conversely, when set to Flase, the code that #ifdef DEV1 branches is commented out.