CMS Snapshot Analysis - Run Analyzer - CPP - Information - Conditions under which header file is set as internal or external

Purpose

The page explains the conditions under which the header file is set as internal/external.

Applicable in CAST Version
Release
Yes/No
8.3.x (tick)
Applicable RDBMS
RDBMS
Yes/No
CSS(tick)
Details

Conditions under which header file is set as internal/external

There are 3 kinds of files (and also of objects):

  • Internal files: First class objects, they are saved, links are traced from them, and diags are computed on them, they are visible in the dashboard.
  • External files: No links starting from them, no diags are computed on them but objects of these files that are the target of links are saved.
  • System files (never saved)

All header files start as external, As soon as a header file contains a declaration for an object, and the definition for this object is in one of the cpp files analyzed in the project, the header file will be marked as internal to this project, and all other objects in that header files will be internal too.

Additional explanation

If we analyze the file foo.cpp , which contains definitions for methods of class Foo, file foo.h (containing the class definition) will automatically be promoted to internal, and class Foo will be saved, and diags will be computed on this class and its methods.

So header files only containing the definition of the calls are promoted as internal and hence seen on the dashboard.

- Sometimes, an object definition can be in a header file (an inline function, a macro definition, a template function). When a header contains only such objects, then there will not be any C++ file that contains a definition for any object in the header (since all definitions are already in the header). So this file will remain external.

- If something else is wrong in the analysis, the link between the header file and C++ file may be lost, and the header will be either totally ignored, or still exist but be external.

The PCH system is a shortcut to read header files much faster (for compilation as well as for analysis). When PCH is correctly configured, we create a file that contains cached data, and when we discover #include, we read this cached data instead of reading the header file itself. For this mechanism to work correctly, the code developer must respect some constraints.
In case if you do not make the classical use of PCH, and do not respect the classical constraints, then when we detect it, we skip retrieving information from the cache file, but it looks like the header files are not read either. So there will be no data from the cache, no data from the headers. It is almost the same as if we tried to analyze the code with some missing headers.
By disabling the PCH processing, we remove the cache file, and we re-enable the (slow) reading of header files, thus enabling the analysis to work again. 

Notes/comments