DoxyPress  1.7.0
Diagrams and Graphs

DoxyPress has built in support to generate inheritance diagrams for C++ classes.

DoxyPress can use the dot program from graphviz to generate more advanced diagrams and graphs. Graphviz is an open-source, cross-platform graph drawing toolkit and can be found at: GraphViz.

Set have-dot to YES in the project file.

DoxyPress uses the dot program to generate the following graphs:

  • A graphical representation of the class hierarchy will be drawn, along with the textual one. Currently this feature is supported for HTML only.
    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.
  • 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.
  • 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.
  • An inverse include dependency graph is also generated showing for a (header) file, which other files include it.
  • A graph is drawn for each documented class and struct that shows:
    • the inheritance relations with base classes.
    • the usage relations with other structs and classes (e.g. class A has a member variable m_a of type class B, then A has an arrow to B with m_a as label).
  • if dot-call is set to YES, a graphical call graph is drawn for each function showing the functions which the function directly or indirectly calls.
  • if dot-called-by is set to YES, a graphical caller graph is drawn for each function showing the functions which the function is directly or indirectly called by.
  • To hide graphs for specific functions refer to \hidecallgraph and \hidecallergraph

Use a layout file to determine which of the graphs are actually shown.

The options dot-graph-max-nodes and dot-graph-max-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:

  • A 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.
  • A white box indicates that the documentation of the class is currently shown.
  • A gray box indicates an undocumented class.
  • A solid dark blue arrow indicates public inheritance.
  • A dashed dark green arrow indicates protected inheritance.
  • A dotted dark green arrow indicates private inheritance.

The elements in the class diagram in LaTeX have the following meaning:

  • A white box indicates a class.
  • A marker in the lower right corner of the box indicates that the class has base classes that are hidden.
  • If the box has a dashed border this indicates virtual inheritance.
  • A solid arrow indicates public inheritance.
  • A dashed arrow indicates protected inheritance.
  • A dotted arrow indicates private inheritance.

The elements in the graphs generated by the dot tool have the following meaning:

  • A white box indicates a class or struct or file.

  • A box with a red border indicates a node that has more arrows than are shown! In other words: the graph is 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 DoxyPress tries to limit the width of the resulting image to 1024 pixels.

  • A black box indicates that the class' documentation is currently shown.
  • A dark blue arrow indicates an include relation (for the include dependency graph) or public inheritance (for the other graphs).
  • A dark green arrow indicates protected inheritance.
  • A dark red arrow indicates private inheritance.

  • A purple dashed arrow indicated a "usage" relation, the edge of the arrow is labeled with the variable(s) responsible for the relation.

    Class A uses class B, if class A has a member variable m of type C, where B is a subtype of C (e.g. C could be B, B*, T<B>*).

Here are a couple of header files that together show the various diagrams that DoxyPress can generate:

diagrams_a.h 

#ifndef _DIAGRAMS_A_H
#define _DIAGRAMS_A_H
class A { public: A *m_self; };
#endif

diagrams_b.h 

#ifndef _DIAGRAMS_B_H
#define _DIAGRAMS_B_H
class A;
class B { public: A *m_a; };
#endif

diagrams_c.h 

#ifndef _DIAGRAMS_C_H
#define _DIAGRAMS_C_H
#include "diagrams_c.h"
class D;
class C : public A { public: D *m_d; };
#endif

diagrams_d.h 

#ifndef _DIAGRAM_D_H
#define _DIAGRAM_D_H
#include "diagrams_a.h"
#include "diagrams_b.h"
class C;
class D : virtual protected  A, private B { public: C m_c; };
#endif

diagrams_e.h 

#ifndef _DIAGRAM_E_H
#define _DIAGRAM_E_H
#include "diagrams_d.h"
class E : public D {};
#endif