4.3.3. C++ Model

Sonargraph uses the Edison Design Group (EDG) C++ Front End for parsing C/C++ code. The EDG parser must be configured appropriately in order to simulate your native C++ compiler. The basic domain model for C++ is shown in the figure below.

C++ Domain Model
Figure 4.4. C++ Domain Model


An important difference to the model of other languages is the fact that C and C++ are using header files to declare items and source files to implement them. Associated header and source files form a logical unit that is called a component in Sonargraph. In other languages like Java components are always represented by single source files. Sonargraph is able to determine the components automatically by looking for declares relationships. If a function is declared in header "function.h" and implemented in a source file "function.cpp" Sonargraph will automatically combine the two into a component called "function". The component is anchored in the directory of the source file.

It is possible for a component to have more than one header file, if the elements implemented in a source file are declared in more than one header file. It is also possible for a component to have more than one source file, if the elements declared in a header file are implemented in more than one source file. It is nevertheless good practice to avoid those situations.

Sometimes it can happen that the automatic creation of components creates overly large components containing unrelated header and source files. That is usually caused by cross declaration, e.g. a global variable is declared in several unrelated header files. If you come over a component that contains unrelated source files you can always analyze the situation by opening the "Component Construction View". To open this view right click on a component in the navigation view and select this view from the context menu. The view will show a graphical representation of all the declares relationships within a component. Using that view it should be easy to find the rogue declarations that cause unrelated files to end up in a single component. You fix the problem by removing the rogue declarations from their header files. Instead you should include the correct header file before using the declared entity.

Sonargraph will attach a warning issue to components that contain more than one header file so that you can easily find components that might be containing unrelated source files. If after inspection you come to the conclusion that the source files in a component are properly related you can ignore the corresponding issue in the issues view (by right clicking on the issue and selecting "Ignore" from the context menu). Ignoring the issue will hide it from the issues view and also will suppress the warning marker that was attached to the component.

Sometimes it is also possible that a component only contains a single header file, e.g. when a class has only inline members. In that case there are situations when it will be impossible for Sonargraph to determine where to anchor such components. To solve this problem Sonargraph will create an artificial module called "Unbound Components" and anchor the component there. The user can then right click on such components and select "Assign to module..." from the context menu. After saving the current system state that decision will be persisted. As soon as the last unbound component has been assigned to a module the artificial module will disappear.

In the example below for example the component "shared" could belong to "module_a" or to "module_b". Only the user is able to resolve that.

Unbound Components