1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
|
/******************************************************************************
*
*
*
* Copyright (C) 1997-2015 by Dimitri van Heesch.
*
* Permission to use, copy, modify, and distribute this software and its
* documentation under the terms of the GNU General Public License is hereby
* granted. No representations are made about the suitability of this software
* for any purpose. It is provided "as is" without express or implied warranty.
* See the GNU General Public License for more details.
*
* Documents produced by Doxygen are derivative works derived from the
* input used in their production; they are not affected by this license.
*
*/
/*! \page diagrams Graphs and diagrams
Doxygen has built-in support to generate inheritance diagrams for C++
classes.
Doxygen can use the "dot" tool from graphviz to generate
more advanced diagrams and graphs. Graphviz is an open-source,
cross-platform graph drawing toolkit and can be found
at https://www.graphviz.org/
If you have the "dot" tool in the path, you can set
\ref cfg_have_dot "HAVE_DOT" to \c YES in the configuration file to
let doxygen use it.
Doxygen uses the "dot" tool to generate the following graphs:
<ul>
<li>A graphical representation of the class hierarchy will be drawn, along
with the textual one. Currently this feature is supported for HTML only.\n
<b>Warning:</b> When you have a very large class hierarchy where many
classes derive from a common base class, the resulting image may become
too big to handle for some browsers.
<li>An inheritance graph will be generated for each documented class showing the
direct and indirect inheritance relations. This disables the
generation of the built-in class inheritance diagrams.
<li>An include dependency graph is generated for each documented file that
includes at least one other file. This feature is currently supported
for HTML and RTF only.
<li>An inverse include dependency graph is also generated showing for
a (header) file, which other files include it.
<li>A graph is drawn for each documented class and struct that shows:
<ul>
<li> the inheritance relations with base classes.
<li> the usage relations with other structs and classes (e.g.
class \c A has a member variable \c m_a of type class \c B, then
\c A has an arrow to \c B with \c m_a as label).
</ul>
<li>if \ref cfg_call_graph "CALL_GRAPH" is set to YES, a
graphical call graph is drawn for each function showing the
functions that the function directly or indirectly calls
(see also section \ref cmdcallgraph "\\callgraph" and
section \ref cmdhidecallgraph "\\hidecallgraph").
<li>if \ref cfg_caller_graph "CALLER_GRAPH" is set to YES, a
graphical caller graph is drawn for each function showing the
functions that the function is directly or indirectly called by
(see also section \ref cmdcallergraph "\\callergraph" and
section \ref cmdhidecallergraph "\\hidecallergraph").
<li>If \ref cfg_directory_graph "DIRECTORY_GRAPH" is set to `YES`, doxygen will
generate graphs that show the directory dependencies for every directory.
The graph will show directories as boxes.
Subdirectories are shown nested into the box of its parent directory.
The depth of the graph is configured through
\ref cfg_dir_graph_max_depth "DIR_GRAPH_MAX_DEPTH".
Include dependencies between the directories are shown as arrows.
</ul>
Using a \ref customize "layout file" you can determine which of the
graphs are actually shown.
The options \ref cfg_dot_graph_max_nodes "DOT_GRAPH_MAX_NODES" and
\ref cfg_max_dot_graph_depth "MAX_DOT_GRAPH_DEPTH" can be used to
limit the size of the various graphs.
The elements in the class diagrams in HTML and RTF
have the following meaning:
<ul>
<li> A \b yellow box indicates a class. A box can have a
little marker in the lower right corner to indicate that the class
contains base classes that are hidden.
For the class diagrams the maximum tree width is currently 8 elements.
If a tree is wider some nodes will be hidden.
If the box is filled with a
dashed pattern the inheritance relation is virtual.
<li> A \b white box indicates that the documentation of the class
is currently shown.
<li> A \b gray box indicates an undocumented class.
<li> A <b>solid dark blue</b> arrow indicates public inheritance.
<li> A <b>dashed dark green</b> arrow indicates protected inheritance.
<li> A <b>dotted dark green</b> arrow indicates private inheritance.
</ul>
The elements in the class diagram in \LaTeX have the
following meaning:
<ul>
<li> A \b white box indicates a class.
A \b marker in the lower right corner of the box indicates that the
class has base classes that are hidden.
If the box has a \b dashed border this indicates virtual inheritance.
<li> A \b solid arrow indicates public inheritance.
<li> A \b dashed arrow indicates protected inheritance.
<li> A \b dotted arrow indicates private inheritance.
</ul>
The elements in the graphs generated by the dot tool have the following
meaning:
<ul>
<li> A \b white box indicates a class or struct or file.
<li> A box with a \b red border indicates a node that has
\e more arrows than are shown!
In other words: the graph is \e truncated with respect to this node.
The reason why a graph is sometimes truncated is to prevent images
from becoming too large.
For the graphs generated with dot doxygen tries
to limit the width of the resulting image to 1024 pixels.
<li> A \b black box indicates that the class' documentation is currently shown.
<li> A <b>dark blue</b> arrow indicates an include relation (for the
include dependency graph) or public inheritance (for the other graphs).
<li> A <b>dark green</b> arrow indicates protected inheritance.
<li> A <b>dark red</b> arrow indicates private inheritance.
<li> A <b>purple dashed</b> arrow indicated a "usage" relation, the
edge of the arrow is labeled with the variable(s) responsible for the
relation.
Class \c A uses class \c B, if class \c A has a member variable \c m
of type C, where B is a subtype of C (e.g. `C` could be `B`, `B*`, `T<B>*`).
</ul>
The elements in the directory dependency graphs have the following meaning:
<ul>
<li> A box with a \b bold border indicates the directory that the
directory dependency graph has been generated for.
<li> A box with a <b>red solid</b> border indicates a directory whose
subdirectories are not shown in the graph ("truncated").
To configure the depth of subdirectories that are shown in the graph
see \ref cfg_dir_graph_max_depth "DIR_GRAPH_MAX_DEPTH".
<li> A box with a <b>red dashed</b> border indicates a truncated
directory whose parent directories are not shown in the graph either.
<li> A box with a \b dashed border other than red indicates that not all
but at least one subdirectory are shown.
<li> A box with a <b>light gray</b> border indicates a directory with both of
the following two attributes:
<ul>
<li> Its parent directory is not shown.
<li> At least one subdirectory is shown.
</ul>
<li> A box with <b>no background color</b> indicates a directory which is not
a subdirectory of the origin's parent directories which are shown.
The origin is the directory for which the directory dependency graph is
shown.
<li> An \b arrow between two boxes indicates an include dependency between
two directories.
The include dependency exists if a file in a directory includes a
file of another directory.
If a directory that is involved in an include dependency is not shown in
the graph, the arrow is attached to the first parent directory that is
shown.
This parent directory is shown as truncated (see above).
</ul>
Here are a couple of header files that together show the various diagrams
that doxygen can generate:
<code>diagrams_a.h</code>
\include diagrams_a.h
<code>diagrams_b.h</code>
\include diagrams_b.h
<code>diagrams_c.h</code>
\include diagrams_c.h
<code>diagrams_d.h</code>
\include diagrams_d.h
<code>diagrams_e.h</code>
\include diagrams_e.h
\htmlonly
Click <a href="examples/diagrams/html/annotated.html">here</a>
for the corresponding HTML documentation that is generated by doxygen.
\endhtmlonly
\latexonly
\IfFileExists{../html/examples/diagrams/latex/refman_doc.tex}
{
See \hyperlink{diagrams_example}{Diagrams example}
for the corresponding \mbox{\LaTeX} documentation that is generated by doxygen.
} {}
\endlatexonly
Note \ref cfg_extract_all "EXTRACT_ALL" \c = \c YES is used to generate the diagrams.
\htmlonly
Go to the <a href="preprocessing.html">next</a> section or return to the
<a href="index.html">index</a>.
\endhtmlonly
*/
|
