C++头文件依赖重构工具ReDHead分析与优化

版权申诉

99 浏览量更新于2024-07-19 收藏 5.61MB PDF 举报

"Masterarbeit_Lukas_Felber.pdf" 这篇硕士论文主要关注的是C++编程语言中的头文件依赖性重构，作者Lukas Felber在HSR - Rapperswil应用科学大学的软件研究所进行了这项研究，并由Prof. Peter Sommerlad指导。论文的标题是"ReDHead-Refactor Dependencies of C/C++ Header Files"，它探讨了C++开发环境，特别是Eclipse CDT（C/C++ Development Tooling）在头文件管理方面的局限性。尽管C++在各种领域广泛应用且效果显著，但在集成开发环境（IDE）的功能和支持方面，长期以来一直落后于如Java等其他语言。虽然有一些C++ IDE提供了有限的重构支持，但它们无法与Eclipse的Java Development Tools提供的功能相提并论。论文的焦点在于开发名为ReDHead的工具，该工具扩展了Eclipse CDT的功能，用于静态分析C++头文件的包含依赖性，并提供优化头文件结构的建议和提示。这些优化的目标主要有三个：(1) 提高代码质量，通过更合理的头文件包含关系，使代码更加清晰和可维护；(2) 减少代码耦合，避免不必要的依赖，使得代码模块化程度更高，更易于理解和测试；(3) 降低编译时间，通过减少不必要的头文件包含，可以减少编译过程中的工作量，从而提高开发效率。 ReDHead工具的实现可能包括对源代码的深度分析，识别无效或冗余的头文件包含，以及提出重构策略，比如引入前置声明、使用局部包含或头文件卫士等最佳实践。此外，工具可能还会提供可视化界面，帮助开发者理解项目中的依赖关系，并辅助进行重构操作。这篇论文对C++开发环境的改进提出了一个创新的解决方案，旨在提升C++开发的效率和质量，与现代软件工程的最佳实践保持同步，尤其是在大型复杂项目中，头文件管理和编译效率往往是关键问题。通过ReDHead工具，开发者能够更好地管理和优化他们的C++项目，从而提高整体的软件质量和开发体验。

code line number in which the vertex origins. The code segments’ lines are numbered

in green on the left-hand side of the source code. In the case of several declaration

references on the same line, the line number is followed by a “ ” and in index number

which indicates the position of the declaration reference on that line. As an example, let

us assume there is a document with the code i = j; on line 15 and a graph containing

the vertex labeled DR15 2. Then, the vertex depicts the 2nd declaration reference which

originates from code line 15, which is j.

Note that a ﬁle-contains edge has been omitted since one can plainly see that all the

declaration and declaration reference vertices would have one, leading to the ﬁle vertex

that contains them.

Also note that each declaration and declaration reference vertex correlates exactly to

one node of an AST. This is very helpful because this will allow to continue the traversal

of the ReDHead graph into the AST and also the other way around.

Figure 2.5 shows the ReDHead graph that correlates to the SDG from Figure 2.1,

which is also contained in the Figure 2.5.

To let the graphs be compared easily, the vertices in the ReDHead graphs are arranged

as similar as possible to the arrangement of the SDG. Obviously, in the SDG there are no

vertices for variable deﬁnition, whereas in the ReDHead graph there are. Some nodes in

the SDG are represented in the ReDHead graph as several declaration reference. These

declaration reference are enveloped by a black, dotted oval which is labeled with the

name of the correlating vertex name in the SDG.

The graph shown in Figure 2.6 depicts the object oriented SDG which was shown in

Figure 2.4. In the ﬁgure, one can also see the include dependencies between diﬀerent

source and header ﬁles. The program’s source code and the SDG of Figure 2.4 including

additional green line numbers necessary to comprehend the ReDHead graph in Figure

2.6, can be found in Figure 2.7.

2.4 Conclusion

As was explained, the Abstract Syntax Tree, the System Dependence Graph and also the

ReDHead graph each are very useful to perform static code analysis. When one focuses

on static include code analysis though, the ReDHead graph, combined with additional

information from ASTs, is the optimal provider for the required information.

3 Used CDT and Eclipse Components

This chapter describes the environment of the ReDHead plugin in detail. There are

reasons given for the choice of the IDE and the used software components, on which

ReDHead will be built upon.

3.1 Eclipse CDT

The plugin that will be developed in the scope of the ReDHead project will be an Eclipse

plugin to be used together with C++ IDE Eclipse CDT. CDT contains a, yet still almost

empty, static analysis framework called Codan, which the ReDHead plugin can hook

itself into. Also, CDT provides access to AST structures for C++ code. Furthermore,

there is the CDT indexer which provides indispensable help when resolving declaration

references.

3.1.1 Compile Conﬁgurations

When developing C++ software, one normally uses a build system like make, cmake,

qmake etc. These build systems are used to assemble the numerous arguments which

will be passed to the compiler that is used to compile the C++ software. These argu-

ments, coming from the build system, combined with a compilers own arguments, result

in a so called compile conﬁguration, which is mainly used by the compiler itself. However,

a key feature to successfully run static software analysis is such a compile conﬁguration.

Without the compile conﬁguration, one could not reliably resolve all dependencies con-

tained in the C++ software since a lot of ambiguous cases would arise.

Acquiring such a compile conﬁguration is a very complex process since there are many

diﬀerent C / C++ compilers which normally comes along with one of several diﬀerent

build system. How costly it can be to obtain such compile conﬁgurations is in detail

described in [BBC

10].

Seen form this point of view, it becomes clear, that to eﬀectively develop static include

analysis for C++ code, a powerful IDE which already provides a suitable compile con-

ﬁguration is required. Since CDT does this, I can safe a lot of time in the development

process of the ReDHead plugin.

3.1.2 AST and Indexer

CDT’s AST and Indexer functionality already provides probably all the basic information

which is needed to statically analyze C++ code. To eﬀectively do so, this information

剩余119页未读，继续阅读

东心十

粉丝: 8693
资源: 42

C++头文件依赖重构工具ReDHead分析与优化

Silicon Photonics Design_ from_devices_to_systems - Lukas Chrostowski.zip

Exp_Arrows_Curves - MetaTrader 5EA.zip

point-and-click-Wildmann_Lukas

lukas-dh.github.io

lukas-batema.github.io:欢迎来到贝特玛开发官网！

AngularJS.in.Action.2015.7.pdf

Angular_Barebones:Lukas的挑战是向Angular Quick Start Repo添加新功能

lzap.github.com：Lukas Zapletal的博客

在kinetis K系列芯片上使用eDMA模拟ADC扫描模式.pdf

论文研究-基于差分抖动的JPEG图像二次压缩检测算法 .pdf

最新资源