Doxygen Manual-1.9.7

Manual for version @VERSION@
Written by Dimitri van Heesch
©1997-2023
Contents
I User Manual 1
1 Introduction 3
2 Installation 7
2.1 Compiling from source on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Installing the binaries on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Compiling from source on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Installing the binaries on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Getting started 11
3.1 Step 0: Check if doxygen supports your programming/hardware description language . . . . . . . . . 12
3.2 Step 1: Creating a configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 Step 2: Running doxygen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1 HTML output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.2 LaTeX output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.3 RTF output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.4 XML output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.5 Man page output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.6 DocBook output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Step 3: Documenting the sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4 Documenting the code 17

4.1 Special comment blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1 Comment blocks for C-like languages (C/C++/C#/Objective-C/PHP/Java) . . . . . . . . . . . 17
Putting documentation after members . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Documentation at other places . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.2 Comment blocks in Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.3 Comment blocks in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.4 Comment blocks in Fortran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 Anatomy of a comment block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5 Markdown support 29
Generated by Doxygen @VERSION@

II
5.1 Standard Markdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1.1 Paragraphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1.2 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1.3 Block quotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1.4 Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1.5 Code Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1.6 Horizontal Rulers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.7 Emphasis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.8 Strikethrough . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.9 code spans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.10 Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Inline Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Reference Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.1.11 Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.12 Automatic Linking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2 Markdown Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2.1 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2.2 Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2.3 Fenced Code Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2.4 Header Id Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2.5 Image Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3 Doxygen specifics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3.1 Including Markdown files as pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.2 Treatment of HTML blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.3 Code Block Indentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.4 Emphasis and strikethrough limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3.5 Code Spans Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3.6 Lists Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.7 Use of asterisks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.8 Limits on markup scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.4 Debugging problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6 Lists 41
7 Grouping 43
7.1 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.2 Member Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.3 Subpaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8 Including formulas 49

III
9 Including tables 51
10 Graphs and diagrams 53
11 Preprocessing 57
12 Automatic link generation 61

12.1 Links to web pages and mail addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
12.2 Links to classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
12.3 Links to files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
12.4 Links to functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
12.5 Links to other members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
12.6 typedefs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
13 Output Formats 65
14 Searching 67
14.1 External Indexing and Searching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
14.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
14.1.2 Configuring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Single project index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Multi project index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
14.1.3 Updating the index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
14.1.4 Programming interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Indexer input format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Search URL format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Search results format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
15 Customizing the output 75

15.1 Minor Tweaks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
15.1.1 Overall Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
15.1.2 Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
15.1.3 Dynamic Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
15.1.4 Header, Footer, and Stylesheet changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
15.2 Changing the layout of pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
15.3 Using the XML output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
16 Custom Commands 83
16.1 Simple aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
16.2 Aliases with arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
16.3 Nesting custom command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
17 Linking to external documentation 85

IV
18 Frequently Asked Questions 87

18.1 How to get information on the index page in HTML? . . . . . . . . . . . . . . . . . . . . . . . . . . 87
18.2 Help, some/all of the members of my class / file / namespace are not documented? . . . . . . . . . . 88
18.3 When I set EXTRACT_ALL to NO none of my functions are shown in the documentation. . . . . . . . 88
18.4 My file with a custom extension is not parsed (properly) (anymore). . . . . . . . . . . . . . . . . . . 88
18.5 How can I make doxygen ignore some code fragment? . . . . . . . . . . . . . . . . . . . . . . . . . 89
18.6 How can I change what is after the #include in the class documentation? . . . . . . . . . . . . . . . 89
18.7 How can I use tag files in combination with compressed HTML? . . . . . . . . . . . . . . . . . . . . 89
18.8 I don't like the quick index that is put above each HTML page, what do I do? . . . . . . . . . . . . . . 90
18.9 The overall HTML output looks different, while I only wanted to use my own html header file . . . . . 90
18.10 Why does doxygen use Qt? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
18.11 How can I exclude all test directories from my directory tree? . . . . . . . . . . . . . . . . . . . . . . 90
18.12 Doxygen automatically generates a link to the class MyClass somewhere in the running text. How do I
prevent that at a certain place? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
18.13 My favorite programming language is X. Can I still use doxygen? . . . . . . . . . . . . . . . . . . . . 91
18.14 Help! I get the cryptic message ïnput buffer overflow, can't enlarge buffer because scanner uses
REJECT¨ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
18.15 When running make in the latex directory I get ¨TeX capacity exceeded¨. Now what? . . . . . . . . . 91
18.16 Why are dependencies via STL classes not shown in the dot graphs? . . . . . . . . . . . . . . . . . 91
18.17 I have problems getting the search engine to work with PHP5 and/or windows . . . . . . . . . . . . . 91
18.18 Can I configure doxygen from the command line? . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
18.19 How did doxygen get its name? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
18.20 What was the reason to develop doxygen? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
18.21 How to prevent interleaved output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
19 Troubleshooting 93
19.1 Known Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
19.2 How to Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
19.3 How to report a bug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
II Reference Manual 97
20 Features 99
21 Doxygen usage 101

21.1 Fine-tuning the output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
22 Doxywizard usage 103

22.1 Wizard tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
22.1.1 Project settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
22.1.2 Mode of operating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
22.1.3 Output to produce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

V
22.1.4 Diagrams to generate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

22.2 Expert tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
22.3 Run tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
22.4 Menu options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
22.4.1 File menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
22.4.2 Settings menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
22.4.3 Help menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
23 Configuration 115
23.1 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
23.2 Project related configuration options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
23.3 Build related configuration options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
23.4 Configuration options related to warning and progress messages . . . . . . . . . . . . . . . . . . . 127
23.5 Configuration options related to the input files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
23.6 Configuration options related to source browsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
23.7 Configuration options related to the alphabetical class index . . . . . . . . . . . . . . . . . . . . . . 132
23.8 Configuration options related to the HTML output . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
23.9 Configuration options related to the LaTeX output . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
23.10 Configuration options related to the RTF output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
23.11 Configuration options related to the man page output . . . . . . . . . . . . . . . . . . . . . . . . . . 147
23.12 Configuration options related to the XML output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
23.13 Configuration options related to the DOCBOOK output . . . . . . . . . . . . . . . . . . . . . . . . . 148
23.14 Configuration options for the AutoGen Definitions output . . . . . . . . . . . . . . . . . . . . . . . . 148
23.15 Configuration options related to Sqlite3 output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
23.16 Configuration options related to the Perl module output . . . . . . . . . . . . . . . . . . . . . . . . . 149
23.17 Configuration options related to the preprocessor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
23.18 Configuration options related to external references . . . . . . . . . . . . . . . . . . . . . . . . . . 150
23.19 Configuration options related to diagram generator tools . . . . . . . . . . . . . . . . . . . . . . . . 151
23.20 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
24 Special Commands 159

24.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
24.2 \addtogroup <name> [(title)] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
24.3 \callgraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
24.4 \hidecallgraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
24.5 \callergraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
24.6 \hidecallergraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
24.7 \showrefby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
24.8 \hiderefby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
24.9 \showrefs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
24.10 \hiderefs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

VI
24.11 \qualifier <label> | ¨(text)¨ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

24.12 \category <name> [<header-file>] [<header-name>] . . . . . . . . . . . . . . . . . . . . . . . . 163
24.13 \class <name> [<header-file>] [<header-name>] . . . . . . . . . . . . . . . . . . . . . . . . . . 163
24.14 \concept <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
24.15 \def <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
24.16 \defgroup <name> (group title) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
24.17 \dir [<path fragment>] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
24.18 \enum <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
24.19 \example['{lineno}'] <file-name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
24.20 \endinternal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
24.21 \extends <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
24.22 \file [<name>] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
24.23 \fileinfo['{'option'}'] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
24.24 \lineinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
24.25 \fn (function declaration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
24.26 \headerfile <header-file> [<header-name>] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
24.27 \hideinitializer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
24.28 \idlexcept <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
24.29 \implements <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
24.30 \ingroup (<groupname> [<groupname>]∗) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
24.31 \interface <name> [<header-file>] [<header-name>] . . . . . . . . . . . . . . . . . . . . . . . . 169
24.32 \internal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
24.33 \mainpage [(title)] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
24.34 \memberof <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
24.35 \name [(header)] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
24.36 \namespace <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
24.37 \nosubgrouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
24.38 \overload [(function declaration)] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
24.39 \package <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
24.40 \page <name> (title) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
24.41 \private . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
24.42 \privatesection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
24.43 \property (qualified property name) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
24.44 \protected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
24.45 \protectedsection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
24.46 \protocol <name> [<header-file>] [<header-name>] . . . . . . . . . . . . . . . . . . . . . . . . . 174
24.47 \public . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
24.48 \publicsection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
24.49 \pure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
24.50 \relates <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

VII
24.51 \related <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

24.52 \relatesalso <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
24.53 \relatedalso <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
24.54 \showinitializer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
24.55 \static . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
24.56 \struct <name> [<header-file>] [<header-name>] . . . . . . . . . . . . . . . . . . . . . . . . . . 175
24.57 \typedef (typedef declaration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
24.58 \union <name> [<header-file>] [<header-name>] . . . . . . . . . . . . . . . . . . . . . . . . . . 176
24.59 \var (variable declaration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
24.60 \vhdlflow [(title for the flow chart)] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
24.61 \weakgroup <name> [(title)] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
24.62 \attention { attention text } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
24.63 \author { list of authors } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
24.64 \authors { list of authors } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
24.65 \brief { brief description } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
24.66 \bug { bug description } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
24.67 \cond [(section-label)] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
24.68 \copyright { copyright description } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
24.69 \date { date description } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
24.70 \showdate ¨<format>¨ [ <date_time> ] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
24.71 \deprecated { description } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
24.72 \details { detailed description } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
24.73 \noop ( text to be ignored ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
24.74 \raisewarning ( text to be shown as warning ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
24.75 \else . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
24.76 \elseif (section-label) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
24.77 \endcond . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
24.78 \endif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
24.79 \exception <exception-object> { exception description } . . . . . . . . . . . . . . . . . . . . . . . . 181
24.80 \if (section-label) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
24.81 \ifnot (section-label) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
24.82 \invariant { description of invariant } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
24.83 \note { text } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
24.84 \par [(paragraph title)] { paragraph } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
24.85 \param '['dir']' <parameter-name> { parameter description } . . . . . . . . . . . . . . . . . . . . . . 183
24.86 \parblock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
24.87 \endparblock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
24.88 \tparam <template-parameter-name> { description } . . . . . . . . . . . . . . . . . . . . . . . . . . 184
24.89 \post { description of the postcondition } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
24.90 \pre { description of the precondition } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

VIII
24.91 \remark { remark text } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

24.92 \remarks { remark text } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
24.93 \result { description of the result value } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
24.94 \return { description of the return value } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
24.95 \returns { description of the return value } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
24.96 \retval <return value> { description } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
24.97 \sa { references } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
24.98 \see { references } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
24.99 \short { short description } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
24.100 \since { text } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
24.101 \test { paragraph describing a test case } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
24.102 \throw <exception-object> { exception description } . . . . . . . . . . . . . . . . . . . . . . . . . . 186
24.103 \throws <exception-object> { exception description } . . . . . . . . . . . . . . . . . . . . . . . . . . 186
24.104 \todo { paragraph describing what is to be done } . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
24.105 \version { version number } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
24.106 \warning { warning message } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
24.107 \xrefitem <key> ¨heading¨ ¨list title¨ { text } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
24.108 \addindex (text) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
24.109 \anchor <word> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
24.110 \cite <label> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
24.111 \endlink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
24.112 \link <link-object> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
24.113 \ref <name> [¨(text)¨] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
24.114 \refitem <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
24.115 \secreflist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
24.116 \endsecreflist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
24.117 \subpage <name> [¨(text)¨] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
24.118 \tableofcontents['{'[option[:level]][,option[:level]]∗'}'] . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
24.119 \section <section-name> (section title) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
24.120 \subsection <subsection-name> (subsection title) . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
24.121 \subsubsection <subsubsection-name> (subsubsection title) . . . . . . . . . . . . . . . . . . . . . 190
24.122 \paragraph <paragraph-name> (paragraph title) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
24.123 \dontinclude['{lineno}'] <file-name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
24.124 \include['{'option'}'] <file-name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
24.125 \includelineno <file-name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
24.126 \includedoc <file-name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
24.127 \line ( pattern ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
24.128 \skip ( pattern ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
24.129 \skipline ( pattern ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
24.130 \snippet['{'option'}'] <file-name> ( block_id ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

IX
24.131 \snippetlineno <file-name> ( block_id ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

24.132 \snippetdoc <file-name> ( block_id ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
24.133 \until ( pattern ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
24.134 \verbinclude <file-name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
24.135 \htmlinclude [¨[block]¨] <file-name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
24.136 \latexinclude <file-name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
24.137 \rtfinclude <file-name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
24.138 \maninclude <file-name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
24.139 \docbookinclude <file-name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
24.140 \xmlinclude <file-name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
24.141 \a <word> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
24.142 \arg { item-description } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
24.143 \b <word> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
24.144 \c <word> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
24.145 \code['{'<word>'}'] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
24.146 \copydoc <link-object> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
24.147 \copybrief <link-object> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
24.148 \copydetails <link-object> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
24.149 \docbookonly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
24.150 \dot [¨caption¨] [<sizeindication>=<size>] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
24.151 \emoji ¨name¨ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
24.152 \msc [¨caption¨] [<sizeindication>=<size>] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
24.153 \startuml ['{'option[,option]'}'] [¨caption¨] [<sizeindication>=<size>] . . . . . . . . . . . . . . . . . . 199
24.154 \dotfile <file> [¨caption¨] [<sizeindication>=<size>] . . . . . . . . . . . . . . . . . . . . . . . . . 200
24.155 \mscfile <file> [¨caption¨] [<sizeindication>=<size>] . . . . . . . . . . . . . . . . . . . . . . . . . 200
24.156 \diafile <file> [¨caption¨] [<sizeindication>=<size>] . . . . . . . . . . . . . . . . . . . . . . . . . 200
24.157 \doxyconfig <config_option> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
24.158 \e <word> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
24.159 \em <word> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
24.160 \endcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
24.161 \enddocbookonly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
24.162 \enddot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
24.163 \endmsc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
24.164 \enduml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
24.165 \endhtmlonly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
24.166 \endlatexonly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
24.167 \endmanonly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
24.168 \endrtfonly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
24.169 \endverbatim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
24.170 \endxmlonly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

X
24.171 \f$ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

24.172 \f( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
24.173 \f) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
24.174 \f[ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
24.175 \f] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
24.176 \f{environment}{ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
24.177 \f} . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
24.178 \htmlonly [¨[block]¨] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
24.179 \image['{'option[,option]'}'] <format> <file> [¨caption¨] [<sizeindication>=<size>] . . . . . . . . . . 204
24.180 \latexonly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
24.181 \manonly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
24.182 \li { item-description } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
24.183 \n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
24.184 \p <word> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
24.185 \rtfonly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
24.186 \verbatim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
24.187 \xmlonly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
24.188 \\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
24.189 \@ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
24.190 \∼[LanguageId] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
24.191 \& . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
24.192 \$ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
24.193 \# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
24.194 \< . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
24.195 \> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
24.196 \% . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
24.197 \¨ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
24.198 \. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
24.199 \= . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
24.200 \:: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
24.201 \| . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
24.202 \– . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
24.203 \— . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
25 HTML Commands 209

25.1 HTML tag commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
25.2 HTML4 character entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
26 XML Commands 217
27 Emoji support 219

XI
27.1 Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

27.2 Emoji image retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
III Developers Manual 221
28 Internationalization 223
29 Perl Module Output 229

29.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
29.2 Using the LaTeX generator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
29.2.1 Creation of PDF and DVI output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
29.3 Documentation format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
29.4 Data structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
29.5 Perl Module Tree Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
30 Doxygen's Internals 237
Appendices 241
A Autolink Example 243

A.1 Class Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
A.1.1 Autolink_Test Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Detailed Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Member Enumeration Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Constructor & Destructor Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Member Function Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
A.2 File Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
A.2.1 autolink.cpp File Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Macro Definition Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Typedef Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Enumeration Type Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Variable Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
B Resolving Typedef Example 247

B.1 Class Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
B.1.1 CoordStruct Struct Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Member Data Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
B.2 File Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
B.2.1 restypedef.cpp File Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

XII

Function Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
C Diagrams Example 249

C.1 Class Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
C.1.1 A Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
C.1.2 B Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
C.1.3 C Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
C.1.4 D Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
C.1.5 E Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
C.2 File Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
C.2.1 diagrams_a.h File Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
C.2.2 diagrams_a.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
C.2.3 diagrams_b.h File Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
C.2.4 diagrams_b.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
C.2.5 diagrams_c.h File Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
C.2.6 diagrams_c.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
C.2.7 diagrams_d.h File Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
C.2.8 diagrams_d.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
C.2.9 diagrams_e.h File Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
C.2.10 diagrams_e.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
D Modules Example 259

D.1 Module Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
D.1.1 The First Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
D.1.2 The Second Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
D.1.3 The Third Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
The Fourth Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
D.1.4 The Fifth Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
D.2 Namespace Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
D.2.1 N1 Namespace Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
D.3 Class Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

XIII
D.3.1 C1 Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

D.4 File Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
D.4.1 group.cpp File Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
E Member Groups Example 263

E.1 Class Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
E.1.1 Memgrp_Test Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
E.2 File Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
E.2.1 memgrp.cpp File Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
F Style Examples 265

F.1 After Block Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
F.1.1 Class Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Afterdoc_Test Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
F.1.2 File Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
afterdoc.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
F.2 QT Style Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
QTstyle_Test Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
F.3 Javadoc Style Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Javadoc_Test Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
F.4 Javadoc Banner Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
F.4.1 File Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
javadoc-banner.h File Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
javadoc-banner.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

XIV
G Structural Commands Example 273

G.1 File Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
G.1.1 structcmd.h File Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
G.1.2 structcmd.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
H Language Examples 277

H.1 Python Docstring Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
H.1.1 Namespace Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
docstring Namespace Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
H.1.2 Class Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
docstring.PyClass Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
H.1.3 File Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
docstring.py File Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
H.2 Python Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
H.2.1 Namespace Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
pyexample Namespace Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
H.2.2 Class Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
pyexample.PyClass Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
H.3 VHDL Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
H.3.1 Design Unit Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
mux_using_with Entity Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
mux_using_with.behavior Architecture Reference . . . . . . . . . . . . . . . . . . . . . . 280
H.3.2 File Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
mux.vhdl File Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
I Class Example 281

I.1 Class Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
I.1.1 Test Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
I.2 File Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
I.2.1 class.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
J Define Example 283

J.1 File Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
J.1.1 define.h File Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

XV

J.1.2 define.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
K Enum Example 285

K.1 Class Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
K.1.1 Enum_Test Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Member Enumeration Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
K.2 File Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
K.2.1 enum.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
L Example Example 287

L.1 Class Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
L.1.1 Example_Test Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
L.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
L.2.1 example_test.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
M Extends/Implements Example 289

M.1 Class Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
M.1.1 Car Struct Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
M.1.2 Object Struct Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
M.1.3 Truck Struct Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
M.1.4 Vehicle Struct Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
M.2 File Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
M.2.1 manual.c File Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
N File Example 293

N.1 File Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
N.1.1 file.h File Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
N.1.2 file.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

XVI
O Fn Example 295
O.1 Class Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
O.1.1 Fn_Test Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
O.2 File Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
O.2.1 func.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
P Overload Example 297

P.1 Class Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
P.1.1 Overload_Test Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Q Page Example 299

Q.1 A documentation page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Q.1.1 An example section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
The first subsection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
The second subsection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Q.2 Another page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
R Relates Example 301

R.1 Class Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
R.1.1 String Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Friends And Related Symbol Documentation . . . . . . . . . . . . . . . . . . . . . . . . . 301
S Author Example 303

S.1 Bug List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
S.2 Class Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
S.2.1 SomeNiceClass Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
T Par Example 305

T.1 Class Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
T.1.1 Par_Test Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
U Include Example 307

U.1 pag_example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
U.2 Class Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
U.2.1 Include_Test Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

XVII

Part I
User Manual
Chapter 1
Introduction
Introduction
Doxygen is the de facto standard tool for generating documentation from annotated C++ sources, but it also supports
other popular programming languages such as C, Objective-C, C#, PHP, Java, Python, IDL (Corba, Microsoft, and
UNO/OpenOffice flavors), Fortran, and to some extent D. Doxygen also supports the hardware description language
VHDL.
Doxygen can help you in three ways:
1. It can generate an on-line documentation browser (in HTML) and/or an off-line reference manual (in LATEX)
from a set of documented source files. There is also support for generating output in RTF (MS-Word), Post←-
Script, hyperlinked PDF, compressed HTML, and Unix man pages. The documentation is extracted directly
from the sources, which makes it much easier to keep the documentation consistent with the source code.
2. You can configure doxygen to extract the code structure from undocumented source files. This is very useful
to quickly find your way in large source distributions. Doxygen can also visualize the relations between the
various elements by means of include dependency graphs, inheritance diagrams, and collaboration diagrams,
which are all generated automatically.
3. You can also use doxygen for creating normal documentation (as I did for the doxygen user manual and
web-site).
Doxygen is developed under Mac OS X and Linux, but is set-up to be highly portable. As a result, it runs on most
other Unix flavors as well. Furthermore, executables for Windows are available.
This manual is divided into three parts, each of which is divided into several sections.
The first part forms a user manual:
• Section Installation discusses how to download, compile and install doxygen for your platform.
• Section Getting started tells you how to generate your first piece of documentation quickly.
• Section Documenting the code demonstrates the various ways that code can be documented.
• Section Markdown support show the Markdown formatting supported by doxygen.
• Section Lists shows how to create lists.
• Section Grouping shows how to group things together.
• Section Including tables shows how to insert tables in the documentation.
• Section Including formulas shows how to insert formulas in the documentation.
• Section Graphs and diagrams describes the diagrams and graphs that doxygen can generate.

4 Introduction
• Section Preprocessing explains how doxygen deals with macro definitions.
• Section Automatic link generation shows how to put links to files, classes, and members in the documentation.
• Section Output Formats shows how to generate the various output formats supported by doxygen.
• Section Searching shows various ways to search in the HTML documentation.
• Section External Indexing and Searching shows how use the external search and index tools
• Section Customizing the output explains how you can customize the output generated by doxygen.
• Section Custom Commands show how to define and use custom commands in your comments.
• Section Linking to external documentation explains how to let doxygen create links to externally generated
documentation.
• Section Frequently Asked Questions gives answers to frequently asked questions.
• Section Troubleshooting tells you what to do when you have problems.
The second part forms a reference manual:
• Section Features presents an overview of what doxygen can do.
• Section Doxygen usage shows how to use the doxygen program.
• Section Doxywizard usage shows how to use the doxywizard program.
• Section Configuration shows how to fine-tune doxygen, so it generates the documentation you want.
• Section Special Commands shows an overview of the special commands that can be used within the docu-
mentation.
• Section HTML Commands shows an overview of the HTML commands that can be used within the documen-
tation.
• Section XML Commands shows an overview of the C# style XML commands that can be used within the
documentation.
• Section Emoji support shows an introduction how emoji can be used within the documentation.
The third part provides information for developers:
• Section Doxygen's Internals gives a global overview of how doxygen is internally structured.
• Section Perl Module Output shows how to use the PerlMod output.
• Section Internationalization explains how to add support for new output languages.
Doxygen license
Copyright © 1997-2023 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.

5
User examples
Doxygen supports a number of output formats where HTML is the most popular one. I've gathered some nice
examples of real-life projects using doxygen.
These are part of a larger list of projects that use doxygen. If you know other projects, let me know
and I'll add them.
Future work
Although doxygen is successfully used by large number of companies and open source projects already, there is
always room for improvement.
You can also submit enhancement requests in the bug tracker.
Acknowledgments
Thanks go to:
• Malte Zöckler and Roland Wunderling, authors of DOC++. The first version of doxygen borrowed some code
of an old version of DOC++. Although I have rewritten practically all code since then, DOC++ has still given
me a good start in writing doxygen.
• All people at Qt Software, for creating a beautiful GUI Toolkit.
• Steffen Schümann for creating ghc::filesystem which is used by doxygen.
• Michael McTernan for creating mscgen which is now embedded in doxygen.
• My brother Frank for rendering the logos.
• Harm van der Heijden for adding HTML help support.
• Wouter Slegers of Your Creative Solutions for registering the www.doxygen.org domain.
• Martin Kreis for adding VHDL support.
• Parker Waechter for adding the RTF output generator.
• Joerg Baumann, for adding conditional documentation blocks, PDF links, and the configuration generator.
• Tim Mensch for adding the todo command.
• Christian Hammond for redesigning the web-site.
• Ken Wong for providing the HTML tree view code.
• Talin for adding support for C# style comments with XML markup.
• Petr Prikryl for coordinating the internationalization support. All language maintainers for providing transla-
tions into many languages.
• many, many others for suggestions, patches and bug reports.

6 Introduction

Chapter 2
Installation
2.1 Compiling from source on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Installing the binaries on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Compiling from source on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Installing the binaries on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
First go to the download page to get the latest distribution, if you have not downloaded doxygen already.
2.1 Compiling from source on UNIX
If you downloaded the source distribution, you need at least the following to build the executable:
• The GNU tools flex, bison, libiconv and GNU make
• You need python (version 2.7 or higher, see https://www.python.org).
• In order to generate a Makefile for your platform, you need cmake version 3.3 or later.
To take full advantage of doxygen's features the following additional tools should be installed.
• Qt Software's GUI toolkit Qt version 5.14 or higher (including Qt 6). This is needed to build the GUI front-end
doxywizard.
• A LATEX distribution: for instance TeX Live This is needed for generating LATEX, Postscript, and PDF output.
• the Graph visualization toolkit version 2.38 or higher Needed for the include
dependency graphs, the graphical inheritance graphs, and the collaboration graphs. If you compile graphviz
yourself, make sure you do include freetype support (which requires the freetype library and header files),
otherwise the graphs will not render proper text labels.
• For formulas in the HTML output (when MathJax is not used) or in case you do not wish to use pdflatex,
the ghostscript interpreter is needed. You can find it at www.ghostscript.com.
Compilation is now done by performing the following steps:
1. Unpack the archive, unless you already have done that:
gunzip doxygen-$VERSION.src.tar.gz # uncompress the archive

tar xf doxygen-$VERSION.src.tar # unpack it
2. Create a build directory (for instance inside the source tree)

8 Installation
cd doxygen-$VERSION
mkdir build
cd build
3. Run cmake with the makefile generator
cmake -G "Unix Makefiles" ..
cmake tries to determine the platform you use, and will look for the requires tools. It will report if something
is missing.
If you have Qt-5.14 or higher installed and want to build the GUI front-end, you should enable it as follows:
cmake -Dbuild_wizard=YES ..
For an overview of other configuration options use
cmake -L ..
4. Compile the program by running make:
make
The program should compile without problems and the binaries (doxygen and optionally doxywizard)
should be available in the bin directory within the build directory.
5. Optional: Generate the user manual.
cmake -Dbuild_doc=YES ..
make docs
To let doxygen generate the HTML and PDF documentation.

The HTML directory within the build directory will now contain the html documentation (just point a HTML
browser to the file index.html in the html directory).
6. Optional: static linking

If you want to build a statically linked version of doxygen that embeds libclang you need to first build LLVM
and clang from sources using the following options:
cmake -DLIBCLANG_BUILD_STATIC=ON \
-DBUILD_SHARED_LIBS=OFF \
-DLLVM_ENABLE_PIC=OFF \
-DLLVM_BUILD_LLVM_DYLIB=OFF \
-DLLVM_BUILD_LLVM_C_DYLIB=OFF \
-DLLVM_ENABLE_TERMINFO=OFF \
path_to_llvm_root_source_dir
and then build doxygen with these options:
cmake -DCMAKE_BUILD_TYPE=Release \
"-DCMAKE_FIND_LIBRARY_SUFFIXES=.a" \
"-ldl;-lz;-lpthread" \
-Duse_libclang=YES \
path_to_doxygen_root_source_dir
2.2 Installing the binaries on UNIX
After the compilation of the source code do a make install to install doxygen. If you downloaded the binary
distribution for Linux, type:
make install
Binaries are installed into the directory /usr/local/bin, man pages in /usr/local/man/man1 and doc-
umentation in /usr/local/doc/doxygen To change this just edit the Makefile.

2.3 Compiling from source on Windows 9
Note
You need the GNU install tool for this to work (it is part of the coreutils package). Other install tools may put
the binaries in the wrong directory!
If you have a RPM or DEB package, then please follow the standard installation procedure that is required for these
packages.
2.3 Compiling from source on Windows
From version 1.8.10 onwards, build files need to be generated by cmake. cmake can be downloaded from
https://cmake.org/download/
At the moment only the community version of Visual Studio 2019 is tested, but other version might also work.
Alternatively, you can compile doxygen the UNIX way using Cygwin or MinGW.
The next step is to install modern versions of bison and flex (see https://sourceforge.←-
net/projects/winflexbison/. After installation and adding them to your path rename win_flex.exe
to flex.exe and win_bison.exe to bison.exe) Furthermore you have to install python (version 2.7 or
higher, see https://www.python.org). These packages are needed during the compilation process.
Download doxygen's source tarball and put it somewhere (e.g. use c:\tools)
Now start a visual studio native command shell (for either x86 or x64) and type
cd c:\tools
tar zxvf doxygen-x.y.z.src.tar.gz
to unpack the sources (you can obtain tar from e.g. https://gnuwin32.sourceforge.←-
net/packages.html). Alternatively you can use an unpack program, like 7-Zip (see https://www.←-
7-zip.org/) or use the built-in unpack feature of modern Windows systems).
Now your environment is setup to generate the required project files for doxygen.
change directory to the doxygen-x.y.z directory, create and change to a build directory
mkdir build
cd build
cmake -G "Visual Studio 14 2015" ..
This will create a project file then can be opened in Visual Studio.
If you prefer compiling from the command prompt you can use the following instead:
mkdir build
cd build
cmake -G "NMake Makefiles" ..
nmake
Note that compiling Doxywizard requires Qt 5.14 or newer (see https://doc.qt.io/).

Also read the next section for additional tools you may need to install to run doxygen with certain features enabled.
2.4 Installing the binaries on Windows
Doxygen comes as a self-installing archive, so installation is extremely simple. Just follow the dialogs.
After installation it is recommended to also download and install GraphViz (version 2.38 or better is highly recom-
mended). Doxygen can use the dot tool of the GraphViz package to render nicer diagrams, see the HAVE_DOT
option in the configuration file.

10 Installation
If you want to produce compressed HTML files (see GENERATE_HTMLHELP) in the configuration file, then you
need the Microsoft HTML help workshop. In the beginning of 2021 Microsoft took the original page, with a.o. the
download links, offline the HTML help workshop was already many years in maintenance mode). You can download
the HTML help workshop from the web archives at Installation executable.
If you want to produce Qt Compressed Help files (see QHG_LOCATION) in the configuration file, then you need
qhelpgenerator which is part of Qt. You can download Qt from Qt Software Downloads.
In order to generate PDF output or use scientific formulas you will also need to install LaTeX and
Ghostscript.
For LATEX a number of distributions exists. Popular ones that should work with doxygen are MikTex and pro←-
TeXt.
Ghostscript can be downloaded from Sourceforge.
After installing LATEX and Ghostscript you'll need to make sure the tools latex.exe, pdflatex.exe, and gswin32c.exe
(or gswin64c.exe) are present in the search path of a command box. Follow these instructions if you are unsure
and run the commands from a command box to verify it works.

Chapter 3
Getting started
3.1 Step 0: Check if doxygen supports your programming/hardware description language . . . . . . . . . 12

3.2 Step 1: Creating a configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 Step 2: Running doxygen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1 HTML output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.2 LaTeX output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.3 RTF output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.4 XML output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.5 Man page output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.6 DocBook output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Step 3: Documenting the sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
The executable doxygen is the main program that parses the sources and generates the documentation. See
section Doxygen usage for more detailed usage information.
Optionally, the executable doxywizard can be used, which is a graphical front-end for editing the configuration
file that is used by doxygen and for running doxygen in a graphical environment. For Mac OS X doxywizard will be
started by clicking on the doxygen application icon.
The following figure shows the relation between the tools and the flow of information between them (it looks complex
but that's only because it tries to be complete):

12 Getting started
Doxywizard Your application custom

output
read doxmlparser lib
generate/edit XML files
Config file
Layout file Doxyfile
make ps postscript
generate generate Latex files latex
read update +
Makefile make pdf PDF
read
Sources Doxygen
read
read generate
Man pages
Custom
− headers
− footers Tag file(s)
− images Windows only
import doc
refman.rtf MS−Word
HTML read chm

pages HTML Help Workshop
Figure 3.1: Doxygen information flow
3.1 Step 0: Check if doxygen supports your programming/hardware

description language
First, assure that your programming/hardware description language has a reasonable chance of being recognized
by doxygen. These programming languages are supported by default: C, C++, Lex, C#, Objective-C, IDL, Java,
PHP, Python, Fortran and D. Doxygen also supports the hardware description language VHDL by default. It is
possible to configure certain file type extensions to use certain parsers: see the Configuration/ExtensionMappings
for details. Also, completely different languages can be supported by using preprocessor programs: see the
Helpers page for details.
3.2 Step 1: Creating a configuration file
Doxygen uses a configuration file to determine all of its settings. Each project should get its own configuration file.
A project can consist of a single source file, but can also be an entire source tree that is recursively scanned.
To simplify the creation of a configuration file, doxygen can create a template configuration file for you. To do this
call doxygen from the command line with the -g option:
doxygen -g <config-file>
where <config-file> is the name of the configuration file. If you omit the file name, a file named Doxyfile will
be created. If a file with the name <config-file> already exists, doxygen will rename it to <config-file>.bak before

3.2 Step 1: Creating a configuration file 13
generating the configuration template. If you use - (i.e. the minus sign) as the file name then doxygen will try to
read the configuration file from standard input (stdin), which can be useful for scripting.
The configuration file has a format that is similar to that of a (simple) Makefile. It consists of a number of assignments
(tags) of the form:
TAGNAME = VALUE or
TAGNAME = VALUE1 VALUE2 ...
You can probably leave the values of most tags in a generated template configuration file to their default value. See
section Configuration for more details about the configuration file.
If you do not wish to edit the configuration file with a text editor, you should have a look at doxywizard, which is a
GUI front-end that can create, read and write doxygen configuration files, and allows setting configuration options
by entering them via dialogs.
For a small project consisting of a few C and/or C++ source and header files, you can leave INPUT tag empty and
doxygen will search for sources in the current directory.
If you have a larger project consisting of a source directory or tree you should assign the root directory or directories
to the INPUT tag, and add one or more file patterns to the FILE_PATTERNS tag (for instance ∗.cpp ∗.h). Only
files that match one of the patterns will be parsed (if the patterns are omitted a list of typical patterns is used for the
types of files doxygen supports). For recursive parsing of a source tree you must set the RECURSIVE tag to YES.
To further fine-tune the list of files that is parsed the EXCLUDE and EXCLUDE_PATTERNS tags can be used. To
omit all test directories from a source tree for instance, one could use:
EXCLUDE_PATTERNS = */test/*
Doxygen looks at the file's extension to determine how to parse a file, using the following table:
Extension Language Extension Language Extension Language

.dox C / C++ .hpp C / C++ .py Python
.doc C / C++ .h++ C / C++ .pyw Python
.c C / C++ .mm C / C++ .f Fortran
.cc C / C++ .txt C / C++ .for Fortran
.cxx C / C++ .idl IDL .f90 Fortran
.cpp C / C++ .ddl IDL .f95 Fortran
.c++ C / C++ .odl IDL .f03 Fortran
.ii C / C++ .java Java .f08 Fortran
.ixx C / C++ .cs C# .f18 Fortran
.ipp C / C++ .d D .vhd VHDL
.i++ C / C++ .php PHP .vhdl VHDL
.inl C / C++ .php4 PHP .ucf VHDL
.h C / C++ .php5 PHP .qsf VHDL
.H C / C++ .inc PHP .l Lex
.hh C / C++ .phtml PHP .md Markdown
.HH C / C++ .m Objective-C .markdown Markdown
.hxx C / C++ .M Objective-C .ice Slice
Please note that the above list might contain more items than that by default set in the FILE_PATTERNS.
Any extension that is not parsed can be set by adding it to FILE_PATTERNS and when the appropriate
EXTENSION_MAPPING is set.
If you start using doxygen for an existing project (thus without any documentation that doxygen is aware of), you
can still get an idea of what the structure is and how the documented result would look like. To do so, you must
set the EXTRACT_ALL tag in the configuration file to YES. Then, doxygen will pretend everything in your sources
is documented. Please note that as a consequence warnings about undocumented members will not be generated

14 Getting started
as long as EXTRACT_ALL is set to YES.

To analyze an existing piece of software it is useful to cross-reference a (documented) entity with its definition in the
source files. Doxygen will generate such cross-references if you set the SOURCE_BROWSER tag to YES. It can
also include the sources directly into the documentation by setting INLINE_SOURCES to YES (this can be handy
for code reviews for instance).
3.3 Step 2: Running doxygen
To generate the documentation you can now enter:
doxygen <config-file>
Depending on your settings doxygen will create html, rtf, latex, xml, man, and/or docbook directories inside
the output directory. As the names suggest these directories contain the generated documentation in HTML, RTF,
LATEX, XML, Unix-Man page, and DocBook format.
The default output directory is the directory in which doxygen is started. The root directory to which the output is
written can be changed using the OUTPUT_DIRECTORY. The format specific directory within the output directory
can be selected using the HTML_OUTPUT, RTF_OUTPUT, LATEX_OUTPUT, XML_OUTPUT, MAN_OUTPUT,
and DOCBOOK_OUTPUT. tags of the configuration file. If the output directory does not exist, doxygen will try to
create it for you (but it will not try to create a whole path recursively, like mkdir -p does).
3.3.1 HTML output
The generated HTML documentation can be viewed by pointing a HTML browser to the index.html file in the
html directory. For the best results a browser that supports cascading style sheets (CSS) should be used (I'm
using Mozilla Firefox, Google Chrome, Safari, and sometimes IE8, IE9, and Opera to test the generated output).
Some of the features the HTML section (such as GENERATE_TREEVIEW or the search engine) require a browser
that supports Dynamic HTML and JavaScript enabled.
3.3.2 LaTeX output
The generated LATEX documentation must first be compiled by a LATEX compiler (I use a recent teTeX distribution for
Linux and MacOSX and MikTex for Windows). To simplify the process of compiling the generated documentation,
doxygen writes a Makefile into the latex directory (on the Windows platform also a make.bat batch file is
generated).
The contents and targets in the Makefile depend on the setting of USE_PDFLATEX. If it is disabled (set to NO),
then typing make in the latex directory a dvi file called refman.dvi will be generated. This file can then be
viewed using xdvi or converted into a PostScript file refman.ps by typing make ps (this requires dvips).
To put 2 pages on one physical page use make ps_2on1 instead. The resulting PostScript file can be send to a
PostScript printer. If you do not have a PostScript printer, you can try to use ghostscript to convert PostScript into
something your printer understands.
Conversion to PDF is also possible if you have installed the ghostscript interpreter; just type make pdf (or make
pdf_2on1).
To get the best results for PDF output you should set the PDF_HYPERLINKS and USE_PDFLATEX tags to YES. In
this case the Makefile will only contain a target to build refman.pdf directly.
3.3.3 RTF output
Doxygen combines the RTF output to a single file called refman.rtf. This file is optimized for importing into the
Microsoft Word. Certain information is encoded using so called fields. To show the actual value you need to select
all (Edit - select all) and then toggle fields (right click and select the option from the drop down menu).

3.4 Step 3: Documenting the sources 15
3.3.4 XML output
The XML output consists of a structured ¨dump¨ of the information gathered by doxygen. Each compound (class/-
namespace/file/...) has its own XML file and there is also an index file called index.xml.
A file called combine.xslt XSLT script is also generated and can be used to combine all XML files into a single
file.
Doxygen also generates two XML schema files index.xsd (for the index file) and compound.xsd (for the
compound files). This schema file describes the possible elements, their attributes and how they are structured, i.e.
it the describes the grammar of the XML files and can be used for validation or to steer XSLT scripts.
In the addon/doxmlparser directory you can find a parser library for reading the XML output pro-
duced by doxygen in an incremental way (see addon/doxmlparser/doxmparser/index.py and
addon/doxmlparser/doxmlparser/compound.py for the interface of the library)
3.3.5 Man page output
The generated man pages can be viewed using the man program. You do need to make sure the man directory is
in the man path (see the MANPATH environment variable). Note that there are some limitations to the capabilities
of the man page format, so some information (like class diagrams, cross references and formulas) will be lost.
3.3.6 DocBook output
Doxygen can also generate output in the DocBook format. How to process the DocBook output is beyond the
scope of this manual.
3.4 Step 3: Documenting the sources
Although documenting the sources is presented as step 3, in a new project this should of course be step 1. Here I
assume you already have some code and you want doxygen to generate a nice document describing the API and
maybe the internals and some related design documentation as well.
If the EXTRACT_ALL option is set to NO in the configuration file (the default), then doxygen will only generate
documentation for documented entities. So how do you document these? For members, classes and namespaces
there are basically two options:
1. Place a special documentation block in front of the declaration or definition of the member, class or names-
pace. For file, class and namespace members it is also allowed to place the documentation directly after the
member.
See section Special comment blocks to learn more about special documentation blocks.
2. Place a special documentation block somewhere else (another file or another location) and put a structural
command in the documentation block. A structural command links a documentation block to a certain entity
that can be documented (e.g. a member, class, namespace or file).
See section Documentation at other places to learn more about structural commands.
The advantage of the first option is that you do not have to repeat the name of the entity.
Files can only be documented using the second option, since there is no way to put a documentation block before
a file. Of course, file members (functions, variables, typedefs, defines) do not need an explicit structural command;
just putting a special documentation block in front or behind them will work fine.
The text inside a special documentation block is parsed before it is written to the HTML and/or LATEX output files.
During parsing the following steps take place:
• Markdown formatting is replaced by corresponding HTML or special commands.

16 Getting started
• The special commands inside the documentation are executed. See section Special Commands for an
overview of all commands.
• If a line starts with some whitespace followed by one or more asterisks (∗) and then optionally more whites-
pace, then all whitespace and asterisks are removed.
• All resulting blank lines are treated as a paragraph separators. This saves you from placing new-paragraph
commands yourself in order to make the generated documentation readable.
• Links are created for words corresponding to documented classes (unless the word is preceded by a %; then
the word will not be linked and the % sign is removed).
• Links to members are created when certain patterns are found in the text. See section Automatic link generation
for more information on how the automatic link generation works.
• HTML tags that are in the documentation are interpreted and converted to LATEX equivalents for the LATEX
output. See section HTML Commands for an overview of all supported HTML tags.

Chapter 4
Documenting the code
4.1 Special comment blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1.1 Comment blocks for C-like languages (C/C++/C#/Objective-C/PHP/Java) . . . . . . . . . . . 17
Putting documentation after members . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Documentation at other places . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.2 Comment blocks in Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.3 Comment blocks in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.4 Comment blocks in Fortran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 Anatomy of a comment block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
This chapter covers two topics:
1. How to put comments in your code such that doxygen incorporates them in the documentation it generates.
This is further detailed in the next section.
2. Ways to structure the contents of a comment block such that the output looks good, as explained in section
Anatomy of a comment block.
4.1 Special comment blocks
A special comment block is a C or C++ style comment block with some additional markings, so doxygen knows it
is a piece of structured text that needs to end up in the generated documentation. The next section presents the
various styles supported by doxygen.
For Python, VHDL, and Fortran code there are different commenting conventions, which can be found in sections
Comment blocks in Python, Comment blocks in VHDL, and Comment blocks in Fortran respectively.
4.1.1 Comment blocks for C-like languages (C/C++/C#/Objective-C/PHP/Java)
For each entity in the code there are two (or in some cases three) types of descriptions, which together form
the documentation for that entity; a brief description and detailed description, both are optional. For methods
and functions there is also a third type of description, the so called in body description, which consists of the
concatenation of all comment blocks found within the body of the method or function.
Having more than one brief or detailed description is allowed (but not recommended, as the order in which the
descriptions will appear is not specified).
As the name suggest, a brief description is a short one-liner, whereas the detailed description provides longer, more
detailed documentation. An ïn body¨ description can also act as a detailed description or can describe a collection

18 Documenting the code
of implementation details. For the HTML output brief descriptions are also used to provide tooltips at places where
an item is referenced.
There are several ways to mark a comment block as a detailed description:
1. You can use the Javadoc style, which consist of a C-style comment block starting with two ∗'s, like this:
/**
* ... text ...
*/
2. or you can use the Qt style and add an exclamation mark (!) after the opening of a C-style comment block,
as shown in this example:
/*!
* ... text ...
*/
In both cases the intermediate ∗'s are optional, so
/*!
... text ...
*/
is also valid.
3. A third alternative is to use a block of at least two C++ comment lines, where each line starts with an additional
slash or an exclamation mark. Here are examples of the two cases:
///
/// ... text ...
///
or
//!
//!... text ...
//!
Note that a blank line ends a documentation block in this case.
4. Some people like to make their comment blocks more visible in the documentation. For this purpose you can
use the following:
/********************************************//**
* ... text
***********************************************/
Note: the 2 slashes to end the normal comment block and start a special comment block.
Note: be careful when using a reformatter like clang-format as it may see this type of comment as 2 separate
comments and introduce spacing between them.
or
/////////////////////////////////////////////////
/// ... text ...
/////////////////////////////////////////////////
or
/************************************************
* ... text
***********************************************/
as long as JAVADOC_BANNER = YES is used.

/**
* A brief history of JavaDoc-style (C-style) comments.
*
* This is the typical JavaDoc-style C-style comment. It starts with two
* asterisks.
*
* @param theory Even if there is only one possible unified theory. it is just a

4.1 Special comment blocks 19
* set of rules and equations.

*/
void cstyle( int theory );
/*******************************************************************************
* A brief history of JavaDoc-style (C-style) banner comments.
*
* This is the typical JavaDoc-style C-style "banner" comment. It starts with
* a forward slash followed by some number, n, of asterisks, where n > 2. It’s
* written this way to be more "visible" to developers who are reading the
* source code.
*
* Often, developers are unaware that this is not (by default) a valid Doxygen
* comment block!
*
* However, as long as JAVADOC_BLOCK = YES is added to the Doxyfile, it will
* work as expected.
*
* This style of commenting behaves well with clang-format.
*
******************************************************************************/
void javadocBanner( int theory );
/***************************************************************************//**
* A brief history of Doxygen-style banner comments.
*
* This is a Doxygen-style C-style "banner" comment. It starts with a "normal"
* comment and is then converted to a "special" comment block near the end of
* the first line. It is written this way to be more "visible" to developers
* who are reading the source code.
* This style of commenting behaves poorly with clang-format.
*
******************************************************************************/
void doxygenBanner( int theory );
See Javadoc Banner example for the corresponding LATEX documentation that is generated by doxygen.
For the brief description there are also several possibilities:
1. One could use the \brief command with one of the above comment blocks. This command ends at the end of
a paragraph, so the detailed description follows after an empty line.
Here is an example:
/*! \brief Brief description.
* Brief description continued.
*
* Detailed description starts here.
*/
2. If JAVADOC_AUTOBRIEF is set to YES in the configuration file, then using Javadoc style comment blocks
will automatically start a brief description which ends at the first dot followed by a space or new line. Here is
an example:
/** Brief description which ends at this dot. Details follow
* here.
*/
The option has the same effect for multi-line special C++ comments:
/// Brief description which ends at this dot. Details follow
/// here.
3. A third option is to use a special C++ style comment which does not span more than one line. Here are two
examples:
/// Brief description.
/** Detailed description. */
or
//! Brief description.
//! Detailed description

//! starts here.

Note the blank line in the last example, which is required to separate the brief description from the block
containing the detailed description. The JAVADOC_AUTOBRIEF should also be set to NO for this case.
As you can see doxygen is quite flexible. If you have multiple detailed descriptions, like in the following example:
//! Brief description, which is

//! really a detailed description since it spans multiple lines.
/*! Another detailed description!
*/
They will be joined. Note that this is also the case if the descriptions are at different places in the code! In this case
the order will depend on the order in which doxygen parses the code.
Unlike most other documentation systems, doxygen also allows you to put the documentation of members (including
global functions) in front of the definition. This way the documentation can be placed in the source file instead of the
header file. This keeps the header file compact, and allows the implementer of the members more direct access to
the documentation. As a compromise the brief description could be placed before the declaration and the detailed
description before the member definition.
Putting documentation after members
If you want to document the members of a file, struct, union, class, or enum, it is sometimes desired to place the
documentation block after the member instead of before. For this purpose you have to put an additional < marker
in the comment block. Note that this also works for the parameters of a function.
Here are some examples:
int var; /*!< Detailed description after the member */
This block can be used to put a Qt style detailed documentation block after a member. Other ways to do the same
are:
int var; /**< Detailed description after the member */
or
int var; //!< Detailed description after the member

//!<
or
int var; ///< Detailed description after the member

///<
Most often one only wants to put a brief description after a member. This is done as follows:
int var; //!< Brief description after the member
or
int var; ///< Brief description after the member
For functions one can use the @param command to document the parameters and then use [in], [out],
[in,out] to document the direction. For inline documentation this is also possible by starting with the direc-
tion attribute, e.g.
void foo(int v /**< [in] docs for input parameter v. */);

Note that these blocks have the same structure and meaning as the special comment blocks in the previous section
only the < indicates that the member is located in front of the block instead of after the block.
Here is an example of the use of these comment blocks:
/*! A test class */
class Afterdoc_Test
{
public:
/** An enum type.
* The documentation block cannot be put after the enum!
*/
enum EnumType
{
int EVal1, /**< enum value 1 */
int EVal2 /**< enum value 2 */
};
void member(); //!< a member function.
protected:
int value; /*!< an integer value */
};
See After Block example for the corresponding LATEX documentation that is generated by doxygen.
Warning
These blocks can only be used to document members and parameters. They cannot be used to document
files, classes, unions, structs, groups, namespaces, macros, and enums themselves. Furthermore, the struc-
tural commands mentioned in the next section (like \class) are not allowed inside these comment blocks.
Be careful using this construct as part of a macro definition, because when MACRO_EXPANSION is set to
YES at the places where the macro is applied, also the comment will be substituted and this comment is then
used as documentation for the last item encountered and not for the macro definition itself!
Examples
Here is an example of a documented piece of C++ code using the Qt style:

//! A test class.
/*!
A more elaborate class description.
*/
class QTstyle_Test
{
public:
//! An enum.
/*! More detailed enum description. */
enum TEnum {
TVal1, /*!< Enum value TVal1. */
TVal2, /*!< Enum value TVal2. */
TVal3 /*!< Enum value TVal3. */
}
//! Enum pointer.
/*! Details. */
*enumPtr,
//! Enum variable.
/*! Details. */
enumVar;
//! A constructor.
/*!
A more elaborate description of the constructor.
*/
QTstyle_Test();
//! A destructor.
/*!
A more elaborate description of the destructor.
*/
~QTstyle_Test();
//! A normal member taking two arguments and returning an integer value.
/*!
\param a an integer argument.
\param s a constant character pointer.
\return The test results
\sa QTstyle_Test(), ~QTstyle_Test(), testMeToo() and publicVar()
*/

int testMe(int a,const char *s);
//! A pure virtual member.

/*!
\sa testMe()
\param c1 the first argument.
\param c2 the second argument.
*/
virtual void testMeToo(char c1,char c2) = 0;
//! A public variable.

/*!
Details.
*/
int publicVar;
//! A function variable.

/*!
Details.
*/
int (*handler)(int a,int b);
};
See QT Style example for the corresponding LATEX documentation that is generated by doxygen.
The brief descriptions are included in the member overview of a class, namespace or file and are printed using a
small italic font (this description can be hidden by setting BRIEF_MEMBER_DESC to NO in the configuration file).
By default the brief descriptions become the first sentence of the detailed descriptions (but this can be changed by
setting the REPEAT_BRIEF tag to NO). Both the brief and the detailed descriptions are optional for the Qt style.
By default a Javadoc style documentation block behaves the same way as a Qt style documentation block. This is
not according the Javadoc specification however, where the first sentence of the documentation block is automat-
ically treated as a brief description. To enable this behavior you should set JAVADOC_AUTOBRIEF to YES in the
configuration file. If you enable this option and want to put a dot in the middle of a sentence without ending it, you
should put a backslash and a space after it. Here is an example:
/** Brief description (e.g.\ using only a few words). Details follow. */
Here is the same piece of code as shown above, this time documented using the Javadoc style and
JAVADOC_AUTOBRIEF set to YES:
/**
* A test class. A more elaborate class description.
*/
class Javadoc_Test
{
public:
/**
* An enum.
* More detailed enum description.
*/
enum TEnum {
TVal1, /**< enum value TVal1. */
TVal2, /**< enum value TVal2. */
TVal3 /**< enum value TVal3. */
}
*enumPtr, /**< enum pointer. Details. */
enumVar; /**< enum variable. Details. */
/**
* A constructor.
* A more elaborate description of the constructor.
*/
Javadoc_Test();
/**
* A destructor.
* A more elaborate description of the destructor.
*/
~Javadoc_Test();
/**
* a normal member taking two arguments and returning an integer value.
* @param a an integer argument.
* @param s a constant character pointer.
* @see Javadoc_Test()
* @see ~Javadoc_Test()

* @see testMeToo()
* @see publicVar()
* @return The test results
*/
int testMe(int a,const char *s);
/**
* A pure virtual member.
* @see testMe()
* @param c1 the first argument.
* @param c2 the second argument.
*/
virtual void testMeToo(char c1,char c2) = 0;
/**
* a public variable.
* Details.
*/
int publicVar;
/**
* a function variable.
* Details.
*/
int (*handler)(int a,int b);
};
See Javadoc Style example for the corresponding LATEX documentation that is generated by doxygen.
Similarly, if one wishes the first sentence of a Qt style documentation block to automatically be treated as a brief
description, one may set QT_AUTOBRIEF to YES in the configuration file.
Documentation at other places
In the examples in the previous section the comment blocks were always located in front of the declaration or
definition of a file, class or namespace or in front or after one of its members. Although this is often comfortable,
there may sometimes be reasons to put the documentation somewhere else. For documenting a file this is even
required since there is no such thing as ïn front of a file¨.
Doxygen allows you to put your documentation blocks practically anywhere (the exception is inside the body of a
function or inside a normal C style comment block).
The price you pay for not putting the documentation block directly before (or after) an item is the need to put a
structural command inside the documentation block, which leads to some duplication of information. So in practice
you should avoid the use of structural commands unless other requirements force you to do so.
Structural commands (like all other commands) start with a backslash (\), or an at-sign (@) if you prefer Javadoc
style, followed by a command name and one or more parameters. For instance, if you want to document the class
Test in the example above, you could have also put the following documentation block somewhere in the input that
is read by doxygen:
/*! \class Test

\brief A test class.
A more detailed class description.

*/
Here the special command \class is used to indicate that the comment block contains documentation for the
class Test. Other structural commands are:
• \struct to document a C-struct.
• \union to document a union.
• \enum to document an enumeration type.
• \fn to document a function.
• \var to document a variable or typedef or enum value.

• \def to document a #define.
• \typedef to document a type definition.
• \file to document a file.
• \namespace to document a namespace.
• \package to document a Java package.
• \interface to document an IDL interface.
See section Special Commands for detailed information about these and many other commands.
To document a member of a C++ class, you must also document the class itself. The same holds for namespaces.
To document a global C function, typedef, enum or preprocessor definition you must first document the file that
contains it (usually this will be a header file, because that file contains the information that is exported to other
source files).
Attention
Let's repeat that, because it is often overlooked: to document global objects (functions, typedefs, enum,
macros, etc), you must document the file in which they are defined. In other words, there must at least be a
/*! \file */
or a
/** @file */
line in this file.
Here is an example of a C header named structcmd.h that is documented using structural commands:
/*! \file structcmd.h
\brief A Documented file.
Details.
*/
/*! \def MAX(a,b)

\brief A macro that returns the maximum of \a a and \a b.
Details.
*/
/*! \var typedef unsigned int UINT32

\brief A type definition for a .
Details.
*/
/*! \var int errno

\brief Contains the last error code.
\warning Not thread safe!

*/
/*! \fn int open(const char *pathname,int flags)

\brief Opens a file descriptor.
\param pathname The name of the descriptor.

\param flags Opening flags.
*/
/*! \fn int close(int fd)

\brief Closes the file descriptor \a fd.
\param fd The descriptor to close.
*/
/*! \fn size_t write(int fd,const char *buf, size_t count)

\brief Writes \a count bytes from \a buf to the filedescriptor \a fd.
\param fd The descriptor to write to.
\param buf The data buffer to write.
\param count The number of bytes to write.
*/
/*! \fn int read(int fd,char *buf,size_t count)

\brief Read bytes from a file descriptor.

\param fd The descriptor to read from.
\param buf The buffer to read into.
\param count The number of bytes to read.
*/
#define MAX(a,b) (((a)>(b))?(a):(b))

typedef unsigned int UINT32;
int errno;
int open(const char *,int);
int close(int);
size_t write(int,const char *, size_t);
int read(int,char *,size_t);
See Structural Commands example for the corresponding LATEX documentation that is generated by doxygen.
Because each comment block in the example above contains a structural command, all the comment blocks could be
moved to another location or input file (the source file for instance), without affecting the generated documentation.
The disadvantage of this approach is that prototypes are duplicated, so all changes have to be made twice! Because
of this you should first consider if this is really needed, and avoid structural commands if possible. I often receive
examples that contain \fn command in comment blocks which are place in front of a function. This is clearly a case
where the \fn command is redundant and will only lead to problems.
When you place a comment block in a file with one of the following extensions .dox, .txt, .doc, .md or
.markdown or when the extension maps to md by means of the EXTENSION_MAPPING then doxygen will hide
this file from the file list.
If you have a file that doxygen cannot parse but still would like to document it, you can show it as-is using
\verbinclude, e.g.
/*! \file myscript.sh

* Look at this nice script:
* \verbinclude myscript.sh
*/
Make sure that the script is explicitly listed in the INPUT or that FILE_PATTERNS includes the .sh extension and
the script can be found in the path set via EXAMPLE_PATH.
4.1.2 Comment blocks in Python
For Python there is a standard way of documenting the code using so called documentation strings ("""). Such
strings are stored in __doc__ and can be retrieved at runtime. Doxygen will extract such comments and assume
they have to be represented in a preformatted way.
"""@package docstring
Documentation for this module.
More details.
"""
def func():
"""Documentation for a function.
More details.
"""
pass
class PyClass:
"""Documentation for a class.
More details.
"""
def __init__(self):
"""The constructor."""
self._memVar = 0;
def PyMethod(self):
"""Documentation for a method."""
pass
See Python Docstring example for the corresponding LATEX documentation that is generated by doxygen.

Note
When using """ none of doxygen's special commands are supported and the text is shown as verbatim text
see \verbatim. To have the doxygen's special commands and have the text as regular documentation instead
of """ use """! or set PYTHON_DOCSTRING to NO in the configuration file.
Instead of """ one can also use '''.
There is also another way to document Python code using comments that start with ¨##¨ or ¨##<¨. These type of
comment blocks are more in line with the way documentation blocks work for the other languages supported by
doxygen and this also allows the use of special commands.
Here is the same example again but now using doxygen style comments:
## @package pyexample
# Documentation for this module.
#
# More details.
## Documentation for a function.

#
# More details.
def func():
pass
## Documentation for a class.

#
# More details.
class PyClass:
## The constructor.
def __init__(self):
self._memVar = 0;
## Documentation for a method.

# @param self The object pointer.
def PyMethod(self):
pass
## A class variable.
classVar = 0;
## @var _memVar
# a member variable
See Python example for the corresponding LATEX documentation that is generated by doxygen.
Since python looks more like Java than like C or C++, you should set OPTIMIZE_OUTPUT_JAVA to YES in the
configuration file.
4.1.3 Comment blocks in VHDL
For VHDL a comment normally start with ¨--¨. Doxygen will extract comments starting with ¨--!¨. There are only two
types of comment blocks in VHDL; a one line ¨--!¨ comment representing a brief description, and a multi-line ¨--!¨
comment (where the ¨--!¨ prefix is repeated for each line) representing a detailed description.
Comments are always located in front of the item that is being documented with one exception: for ports the
comment can also be after the item and is then treated as a brief description for the port.
Here is an example VHDL file with doxygen comments:
-------------------------------------------------------
--! @file
--! @brief 2:1 Mux using with-select
-------------------------------------------------------
--! Use standard library

library ieee;
--! Use logic elements
use ieee.std_logic_1164.all;
--! Mux entity brief description
--! Detailed description of this

--! mux design element.
entity mux_using_with is
port (
din_0 : in std_logic; --! Mux first input
din_1 : in std_logic; --! Mux Second input
sel : in std_logic; --! Select input

4.2 Anatomy of a comment block 27
mux_out : out std_logic --! Mux output

);
end entity;
--! @brief Architecture definition of the MUX

--! @details More details about this mux element.
architecture behavior of mux_using_with is
begin
with (sel) select
mux_out <= din_0 when ’0’,
din_1 when others;
end architecture;
See VHDL example for the corresponding LATEX documentation that is generated by doxygen.
As of VHDL 2008 it is also possible to use /∗ style comments.
Doxygen will handle /∗ ... ∗/as plain comments and /∗! ... ∗/ style comments as special comments
to be parsed by doxygen.
To get proper looking output you need to set OPTIMIZE_OUTPUT_VHDL to YES in the configuration file. This will
also affect a number of other settings. When they were not already set correctly doxygen will produce a warning
telling which settings where overruled.
4.1.4 Comment blocks in Fortran
When using doxygen for Fortran code you should set OPTIMIZE_FOR_FORTRAN to YES.
The parser tries to guess if the source code is fixed format Fortran or free format Fortran code. This may not always
be correct. If not one should use EXTENSION_MAPPING to correct this. By setting EXTENSION_MAPPING =
f=FortranFixed f90=FortranFree files with extension f are interpreted as fixed format Fortran code and
files with extension f90 are interpreted as free format Fortran code.
For Fortran ¨!>¨ or ¨!<¨ starts a comment and ¨!!¨ or ¨!>¨ can be used to continue an one line comment into a
multi-line comment.
Here is an example of a documented Fortran subroutine:
!> Build the restriction matrix for the aggregation
!! method.
!! @param aggr information about the aggregates
!! @todo Handle special case
subroutine intrestbuild(A,aggr,Restrict,A_ghost)
implicit none
Type(SpMtx), intent(in) :: A !< our fine level matrix
Type(Aggrs), intent(in) :: aggr
Type(SpMtx), intent(out) :: Restrict !< Our restriction matrix
!...
end subroutine
As an alternative you can also use comments in fixed format code:

C> Function comment
C> another line of comment
function a(i)
C> input parameter
integer i
end function A
4.2 Anatomy of a comment block
The previous section focused on how to make the comments in your code known to doxygen, it explained the
difference between a brief and a detailed description, and the use of structural commands.
In this section we look at the contents of the comment block itself.
Doxygen supports various styles of formatting your comments.
The simplest form is to use plain text. This will appear as-is in the output and is ideal for a short description.
For longer descriptions you often will find the need for some more structure, like a block of verbatim text, a list, or
a simple table. For this doxygen supports the Markdown syntax, including parts of the Markdown Extra
extension.

Markdown is designed to be very easy to read and write. Its formatting is inspired by plain text mail. Markdown
works great for simple, generic formatting, like an introduction page for your project. Doxygen also supports reading
of markdown files directly. For more details see chapter Markdown support.
For programming language specific formatting doxygen has two forms of additional markup on top of Markdown
formatting.
1. Javadoc like markup. See Special Commands for a complete overview of all commands supported by
doxygen.
2. XML markup as specified in the C# standard. See XML Commands for the XML commands supported
by doxygen.
If this is still not enough doxygen also supports a subset of the HTML markup language.

Chapter 5
Markdown support
Markdown support was introduced in doxygen version 1.8.0. It is a plain text formatting syntax written by John
Gruber, with the following underlying design goal:
The design goal for Markdown's formatting syntax is to make it as readable as possible. The idea is
that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it's
been marked up with tags or formatting instructions. While Markdown's syntax has been influenced by
several existing text-to-HTML filters, the single biggest source of inspiration for Markdown's syntax is
the format of plain text email.
In the next section the standard Markdown features are briefly discussed. The reader is referred to the Markdown
site for more details.
Some enhancements were made, for instance PHP Markdown Extra, and GitHub flavored
Markdown. The section Markdown Extensions discusses the extensions that doxygen supports.
Finally section Doxygen specifics discusses some specifics for doxygen's implementation of the Markdown stan-
dard.
5.1 Standard Markdown
5.1.1 Paragraphs
Even before doxygen had Markdown support it supported the same way of paragraph handling as Markdown: to
make a paragraph you just separate consecutive lines of text by one or more blank lines.
An example:
Here is text for one paragraph.
We continue with more text in another paragraph.
5.1.2 Headers
Just like Markdown, doxygen supports two types of headers

Level 1 or 2 headers can be made as the follows
This is a level 1 header

========================
This is a level 2 header

------------------------

30 Markdown support
A header is followed by a line containing only ='s or -'s. Note that the exact amount of ='s or -'s is not important as
long as there are at least two.
Alternatively, you can use #'s at the start of a line to make a header. The number of #'s at the start of the line
determines the level (up to 6 levels are supported). You can end a header by any number of #'s.
Here is an example:
# This is a level 1 header
### This is level 3 header #######
5.1.3 Block quotes
Block quotes can be created by starting each line with one or more >'s, similar to what is used in text-only emails.
> This is a block quote

> spanning multiple lines
Lists and code blocks (see below) can appear inside a quote block. Quote blocks can also be nested.
Note that doxygen requires that you put a space after the (last) > character to avoid false positives, i.e. when writing
0 if OK\n
>1 if NOK
the second line will not be seen as a block quote.
5.1.4 Lists
Simple bullet lists can be made by starting a line with -, +, or ∗.
- Item 1
More text for this item.
- Item 2
+ nested list item.
+ another nested item.
- Item 3
List items can span multiple paragraphs (if each paragraph starts with the proper indentation) and lists can be
nested. You can also make a numbered list like so
1. First item.
2. Second item.
Make sure to also read Lists Extensions for doxygen specifics.
5.1.5 Code Blocks
Preformatted verbatim blocks can be created by indenting each line in a block of text by at least 4 extra spaces
This a normal paragraph
This is a code block
We continue with a normal paragraph again.

5.1 Standard Markdown 31
Doxygen will remove the mandatory indentation from the code block. Note that you cannot start a code block in the
middle of a paragraph (i.e. the line preceding the code block must be empty).
See section Code Block Indentation for more info how doxygen handles indentation as this is slightly different than
standard Markdown.
5.1.6 Horizontal Rulers
A horizontal ruler will be produced for lines containing at least three or more hyphens, asterisks, or underscores.
The line may also include any amount of whitespace.
Examples:
- - -
______
Note that using asterisks in comment blocks does not work. See Use of asterisks for details.
Note that when using hyphens and the previous line is not empty you have to use at least one whitespace in the
sequence of hyphens otherwise it might be seen as a level 2 header (see Headers).
5.1.7 Emphasis
To emphasize a text fragment you start and end the fragment with an underscore or star. Using two stars or
underscores will produce strong emphasis.
Examples:
*single asterisks*
_single underscores_
**double asterisks**
__double underscores__
See section Emphasis and strikethrough limits for more info how doxygen handles emphasis / strikethrough spans
slightly different than standard / Markdown GitHub Flavored Markdown.
5.1.8 Strikethrough
To strikethrough a text fragment you start and end the fragment with two tildes.
Examples:
~~double tilde~~
See section Emphasis and strikethrough limits for more info how doxygen handles emphasis / strikethrough spans
slightly different than standard Markdown / GitHub Flavored Markdown.
5.1.9 code spans
To indicate a span of code, you should wrap it in backticks (`). Unlike code blocks, code spans appear inline in a
paragraph. An example:
Use the ‘printf()‘ function.
To show a literal backtick or single quote inside a code span use double backticks, i.e.

32 Markdown support
To assign the output of command ‘ls‘ to ‘var‘ use ‘‘var=‘ls‘‘‘.
To assign the text ’text’ to ‘var‘ use ‘‘var=’text’‘‘.
See section Code Spans Limits for more info how doxygen handles code spans slightly different than standard
Markdown.
5.1.10 Links
Doxygen supports both styles of make links defined by Markdown: inline and reference.
For both styles the link definition starts with the link text delimited by [square brackets].
Inline Links
For an inline link the link text is followed by a URL and an optional link title which together are enclosed in a set of
regular parenthesis. The link title itself is surrounded by quotes.
Examples:
[The link text](http://example.net/)

[The link text](http://example.net/ "Link title")
[The link text](/relative/path/to/index.html "Link title")
[The link text](somefile.html)
In addition doxygen provides a similar way to link a documented entity:
[The link text](@ref MyClass)
in case the first non whitespace character of the reference is a # this is interpreted as a doxygen link and replaced
as a @ref command:
[The link text](#MyClass)
will be interpreted as:
@ref MyClass "The link text"
Reference Links
Instead of putting the URL inline, you can also define the link separately and then refer to it from within the text.
The link definition looks as follows:
[link name]: http://www.example.com "Optional title"
Instead of double quotes also single quotes or parenthesis can be used for the title part.
Once defined, the link looks as follows
[link text][link name]
If the link text and name are the same, also
[link name][]
or even

5.2 Markdown Extensions 33
[link name]
can be used to refer to the link. Note that the link name matching is not case sensitive as is shown in the following
example:
I get 10 times more traffic from [Google] than from

[Yahoo] or [MSN].
[google]: http://google.com/ "Google"

[yahoo]: http://search.yahoo.com/ "Yahoo Search"
[msn]: http://search.msn.com/ "MSN Search"
Link definitions will not be visible in the output.

Like for inline links doxygen also supports @ref inside a link definition:
[myclass]: @ref MyClass "My class"
5.1.11 Images
Markdown syntax for images is similar to that for links. The only difference is an additional ! before the link text.
Examples:
![Caption text](/path/to/img.jpg)
![Caption text](/path/to/img.jpg "Image title")
![Caption text][img def]
![img def]
[img def]: /path/to/img.jpg "Optional Title"
Also here you can use @ref to link to an image:
![Caption text](@ref image.png)

![img def]
[img def]: @ref image.png "Caption text"
The caption text is optional.
5.1.12 Automatic Linking
To create a link to an URL or e-mail address Markdown supports the following syntax:
<http://www.example.com>
<https://www.example.com>
<ftp://www.example.com>
<mailto:address@example.com>
<address@example.com>
Note that doxygen will also produce the links without the angle brackets.
5.2 Markdown Extensions
5.2.1 Table of Contents
Doxygen supports a special link marker [TOC] which can be placed in a page to produce a table of contents at the
start of the page, listing all sections.

34 Markdown support
Note that using [TOC] is the same as using a \tableofcontents command.

Note that the TOC_INCLUDE_HEADINGS has to be set to a value > 0 otherwise no table of contents is shown
when using Markdown Headers.
5.2.2 Tables
Of the features defined by ¨Markdown Extra¨ is support for simple tables:

A table consists of a header line, a separator line, and at least one row line. Table columns are separated by the
pipe (|) character.
Here is an example:
First Header | Second Header

------------- | -------------
Content Cell | Content Cell
Content Cell | Content Cell
which will produce the following table:
First Header Second Header

Content Cell Content Cell
Content Cell Content Cell
Column alignment can be controlled via one or two colons at the header separator line:
| Right | Center | Left |

| ----: | :----: | :---- |
| 10 | 10 | 10 |
| 1000 | 1000 | 1000 |
which will look as follows:
Right Center Left

10 10 10
1000 1000 1000
Additionally, column and row spans are supported. Using a caret (¨∧ ¨) in a cell indicates that the cell above should
span rows. Sequences of carets may be used for any number of row spans. For example:

| ----: | :----: | :---- |
| 10 | 10 | 10 |
| ^ | 1000 | 1000 |
Right Center Left

10 10
10
1000 1000
Column spans are supported by means of directly adjacent vertical bars (¨|¨). Each additional vertical bar indicates
an additional column to be spanned. To put it another way, a single vertical bar indicates a single column span, two
vertical bars indicates a 2 columns span, and so on. For example:

5.2 Markdown Extensions 35
| ----: | :----: | :---- |

| 10 | 10 | 10 |
| 1000 |||
Right Center Left

10 10 10
1000
For more complex tables in doxygen please have a look at: Including tables
5.2.3 Fenced Code Blocks
Another feature defined by ¨Markdown Extra¨ is support for fenced code blocks:
A fenced code block does not require indentation, and is defined by a pair of ¨fence lines¨. Such a line consists of
3 or more tilde (∼) characters on a line. The end of the block should have the same number of tildes. Here is an
example:
This is a paragraph introducing:
~~~~~~~~~~~~~~~~~~~~~
a one-line code block
~~~~~~~~~~~~~~~~~~~~~
By default the output is the same as for a normal code block.

For languages supported by doxygen you can also make the code block appear with syntax highlighting. To do
so you need to indicate the typical file extension that corresponds to the programming language after the opening
fence. For highlighting according to the Python language for instance, you would need to write the following:
~~~~~~~~~~~~~{.py}
# A class
class Dummy:
pass
~~~~~~~~~~~~~
which will produce:

# A class
class Dummy:
pass
and for C you would write:
~~~~~~~~~~~~~~~{.c}
int func(int a,int b) { return a*b; }
~~~~~~~~~~~~~~~
which will produce:

int func(int a,int b) { return a*b; }
The curly braces and dot are optional by the way.

Another way to denote fenced code blocks is to use 3 or more backticks (): @iverbatim also a fenced code
block ``@endiverbatim\ilinebr For the image formatsdot,mscandplantuml` the fenced block
will be shown as an image provided the image format is enabled (see HAVE_DOT and PLANTUML_JAR_PATH),
otherwise it is shown as plain code.
Example:
```plantuml
Alice -> Bob
```

36 Markdown support
or
```plantuml
@startuml
Alice -> Bob
@enduml
```
5.2.4 Header Id Attributes
Standard Markdown has no support for labeling headers, which is a problem if you want to link to a section.
PHP Markdown Extra allows you to label a header by adding the following to the header
Header 1 {#labelid}
========
## Header 2 ## {#labelid2}
To link to a section in the same comment block you can use
[Link text](#labelid)
to link to a section in general, doxygen allows you to use @ref
[Link text](@ref labelid)
Note this only works for the headers of level 1 to 4.
5.2.5 Image Attributes
Standard Markdown has no support for controlling image dimensions which results in less flexibility when writing
docs.
PHP Markdown Extra allows you to add extra attributes to an image as in:
![Caption text](/path/to/img.jpg){attributes}
To allow for output format specific attributes the following syntax is supported
![Caption text](/path/to/img.jpg){format: attributes, format: attributes}
For a description of the possibilities see the paragraph Size indication for the \image command.
For example:
![Doxygen Logo](https://www.doxygen.org/images/doxygen.png){html: width=50%, latex: width=5cm}
5.3 Doxygen specifics
Even though doxygen tries to following the Markdown standard as closely as possible, there are couple of deviation
and doxygen specifics additions.

5.3 Doxygen specifics 37
5.3.1 Including Markdown files as pages
Doxygen can process files with Markdown formatting. For this to work the extension for such a file should be .md
or .markdown (see EXTENSION_MAPPING if your Markdown files have a different extension, and use md as the
name of the parser). Each file is converted to a page (see the page command for details).
By default the name and title of the page are derived from the file name. If the file starts with a level 1 header
however, it is used as the title of the page. If you specify a label for the header (as shown in Header Id Attributes)
doxygen will use that as the page name.
If the label is called index or mainpage doxygen will put the documentation on the front page (index.html).
Here is an example of a file README.md that will appear as the main page when processed by doxygen:
My Main Page {#mainpage}

============
Documentation that will appear on the main page
If a page has a label you can link to it using @ref as is shown above. To refer to a markdown page without such
label you can simple use the file name of the page, e.g.
See [the other page](other.md) for more info.
5.3.2 Treatment of HTML blocks
Markdown is quite strict in the way it processes block-level HTML:
block-level HTML elements — e.g. <div>, <table>, <pre>, <p>, etc. — must be separated
from surrounding content by blank lines, and the start and end tags of the block should not be indented
with tabs or spaces.
Doxygen does not have this requirement, and will also process Markdown formatting inside such HTML blocks. The
only exception is <pre> blocks, which are passed untouched (handy for ASCII art).
Doxygen will not process Markdown formatting inside verbatim or code blocks, and in other sections that need to
be processed without changes (for instance formulas or inline dot graphs).
5.3.3 Code Block Indentation
Markdown allows both a single tab or 4 spaces to start a code block. Since doxygen already replaces tabs by
spaces before doing Markdown processing, the effect will only be same if TAB_SIZE in the configuration file has
been set to 4. When it is set to a higher value spaces will be present in the code block. A lower value will prevent a
single tab to be interpreted as the start of a code block.
With Markdown any block that is indented by 4 spaces (and 8 spaces inside lists) is treated as a code block. This
indentation amount is absolute, i.e. counting from the start of the line.
Since doxygen comments can appear at any indentation level that is required by the programming language, it uses
a relative indentation instead. The amount of indentation is counted relative to the preceding paragraph. In case
there is no preceding paragraph (i.e. you want to start with a code block), the minimal amount of indentation of the
whole comment block is used as a reference.
In most cases this difference does not result in different output. Only if you play with the indentation of paragraphs
the difference is noticeable:
text
text
text
code

38 Markdown support
In this case Markdown will put the word code in a code block, whereas doxygen will treat it as normal text, since
although the absolute indentation is 4, the indentation with respect to the previous paragraph is only 1.
Note that list markers are not counted when determining the relative indent:
1. Item1
More text for item1
2. Item2
Code block for item2
For Item1 the indentation is 4 (when treating the list marker as whitespace), so the next paragraph ¨More text...¨
starts at the same indentation level and is therefore not seen as a code block.
5.3.4 Emphasis and strikethrough limits
Unlike standard Markdown and Github Flavored Markdown doxygen will not touch internal underscores or stars or
tildes, so the following will appear as-is:
a_nice_identifier
Furthermore, a ∗ or _ only starts an emphasis and a ∼ only starts a strikethrough if
• it is followed by an alphanumerical character, and
• it is preceded by a space, newline, or one the following characters <{([,:;
An emphasis or a strikethrough ends if
• it is not followed by an alphanumerical character, and
• it is not preceded by a space, newline, or one the following characters ({[<=+-\@
The span of the emphasis or strikethrough is limited to a single paragraph.

Lastly, note that when you want to put emphasis on a piece of text at the start of a line by means of ∗s within a C-
style doxygen comment block (i.e. /∗∗ ... ∗/) that does not have leading ∗ as column ¨lineup¨, then doxygen
will see the sequence of ∗s at the beginning of the line as ¨lineup¨ and not as emphasis. So the following will not
render as bold:
/**
**this is not bold**
*/
however this will render as bold:
/**
* **this is bold**
*/
5.3.5 Code Spans Limits
Note that unlike standard Markdown, doxygen leaves the following untouched.
A ‘cool’ word in a ‘nice’ sentence.
In other words; a single quote cancels the special treatment of a code span wrapped in a pair of backtick characters.
This extra restriction was added for backward compatibility reasons.
In case you want to have single quotes inside a code span, don't use one backtick but two backticks around the
code span.

5.3 Doxygen specifics 39
5.3.6 Lists Extensions
With Markdown two lists separated by an empty line are joined together into a single list which can be rather
unexpected and many people consider it to be a bug. Doxygen, however, will make two separate lists as you would
expect.
Example:
- Item1 of list 1
- Item2 of list 1
1. Item1 of list 2
2. Item2 of list 2
With Markdown the actual numbers you use to mark the list have no effect on the HTML output Markdown produces.
I.e. standard Markdown treats the following as one list with 3 numbered items:
1. Item1
1. Item2
1. Item3
Doxygen however requires that the numbers used as marks are in strictly ascending order, so the above example
would produce 3 lists with one item. An item with an equal or lower number than the preceding item, will start a new
list. For example:
1. Item1 of list 1
3. Item2 of list 1
2. Item1 of list 2
4. Item2 of list 2
will produce:
1. Item1 of list 1
2. Item2 of list 1
1. Item1 of list 2
2. Item2 of list 2
Historically doxygen has an additional way to create numbered lists by using -# markers:
-# item1
-# item2
5.3.7 Use of asterisks
Special care has to be taken when using ∗'s in a comment block to start a list or make a ruler.
Doxygen will strip off any leading ∗'s from the comment before doing Markdown processing. So although the
following works fine
/** A list:
* * item1
* * item2
*/
When you remove the leading ∗'s doxygen will strip the other stars as well, making the list disappear!
Rulers created with ∗'s will not be visible at all. They only work in Markdown files.

40 Markdown support
5.3.8 Limits on markup scope
To avoid that a stray ∗ or _ matches something many paragraphs later, and shows everything in between with
emphasis, doxygen limits the scope of a ∗ and _ to a single paragraph.
For a code span, between the starting and ending backtick only two new lines are allowed.
Also for links there are limits; the link text, and link title each can contain only one new line, the URL may not contain
any newlines.
5.4 Debugging problems
When doxygen parses the source code it first extracts the comments blocks, then passes these through the
Markdown preprocessor. The output of the Markdown preprocessing consists of text with special commands and
HTML commands. A second pass takes the output of the Markdown preprocessor and converts it into the various
output formats.
During Markdown preprocessing no errors are produced. Anything that does not fit the Markdown syntax is simply
passed on as-is. In the subsequent parsing phase this could lead to errors, which may not always be obvious as
they are based on the intermediate format.
To see the result after Markdown processing you can run doxygen with the -d Markdown option. It will then print
each comment block before and after Markdown processing.

Chapter 6
Lists
Doxygen provides a number of ways to create lists of items.

Using dashes
By putting a number of column-aligned minus (-) signs at the start of a line, a bullet list will automatically be gener-
ated. Instead of the minus sign also plus (+) or asterisk (∗) can be used.
Numbered lists can also be generated by using a minus followed by a hash or by using a number followed by a dot.
Nesting of lists is allowed and is based on indentation of the items.
Here is an example:
/*!
* A list of events:
* - mouse events
* -# mouse move event
* -# mouse click event\n
* More info about the click event.
* -# mouse double click event
* - keyboard events
* 1. key down event
* 2. key up event
*
* More text here.
*/
The result will be:

A list of events:
• mouse events
1. mouse move event

2. mouse click event
More info about the click event.
3. mouse double click event
• keyboard events
1. key down event

2. key up event
More text here.

If you use tabs for indentation within lists, please make sure that TAB_SIZE in the configuration file is set to the
correct tab size.

42 Lists
You can end a list by starting a new paragraph or by putting a dot (.) on an empty line at the same indentation level
as the list you would like to end.
Here is an example that speaks for itself:
/**
* Text before the list
* - list item 1
* - sub item 1
* - sub sub item 1
* - sub sub item 2
* .
* The dot above ends the sub sub item list.
*
* More text for the first sub item
* .
* The dot above ends the first sub item.
*
* More text for the first list item
* - sub item 2
* - sub item 3
* - list item 2
* .
* More text in the same paragraph.
*
* More text in a new paragraph.
*/
Using HTML commands

If you like you can also use HTML commands inside the documentation blocks.
Here is the above example with HTML commands:
/*!
* A list of events:
* <ul>
* <li> mouse events
* <ol>
* <li>mouse move event
* <li>mouse click event<br>
* More info about the click event.
* <li>mouse double click event
* </ol>
* <li> keyboard events
* <ol>
* <li>key down event
* <li>key up event
* </ol>
* </ul>
* More text here.
*/
Note
In this case the indentation is not important.
Using \arg or \li

For compatibility with the Qt Software's internal documentation tool qdoc and with KDoc, doxygen has two com-
mands that can be used to create simple unnested lists.
See \arg and \li for more info.

Chapter 7
Grouping
Doxygen has three mechanisms to group things together. One mechanism works at a global level, creating a new
page for each group. These groups are called 'modules' in the documentation. The second mechanism works within
a member list of some compound entity, and is referred to as a 'member groups'. For pages there is a third grouping
mechanism referred to as subpaging.
7.1 Modules
Modules are a way to group things together on a separate page. You can document a group as a whole, as well
as all individual members. Members of a group can be files, namespaces, classes, functions, variables, enums,
typedefs, and defines, but also other groups.
To define a group, you should put the \defgroup command in a special comment block. The first argument of the
command is a label that should uniquely identify the group.
The second argument is the name or title of the group as it should appear in the documentation.
You can make an entity a member of a specific group by putting a \ingroup command inside its documentation block.
To avoid putting \ingroup commands in the documentation for each member you can also group members together
by the open marker @{ before the group and the closing marker @} after the group. The markers can be put in the
documentation of the group definition or in a separate documentation block.
Groups themselves can also be nested using these grouping markers.
You will get an error message when you use the same group label more than once. If you don't want doxygen to
enforce unique labels, then you can use \addtogroup instead of \defgroup. It can be used exactly like \defgroup, but
when the group has been defined already, then it silently merges the existing documentation with the new one. The
title of the group is optional for this command, so you can use
/** \addtogroup <label>

* @{
*/
...
/** @}*/
to add additional members to a group that is defined in more detail elsewhere.

Note that compound entities (like classes, files and namespaces) can be put into multiple groups, but members (like
variable, functions, typedefs and enums) can only be a member of one group (this restriction is in place to avoid
ambiguous linking targets in case a member is not documented in the context of its class, namespace or file, but
only visible as part of a group).
Doxygen will put members into the group whose definition has the highest ¨priority¨: e.g. An explicit \ingroup
overrides an implicit grouping definition via @{ @}. Conflicting grouping definitions with the same priority trigger a
warning, unless one definition was for a member without any explicit documentation.

44 Grouping
The following example puts VarInA into group A and silently resolves the conflict for IntegerVariable by putting it into
group IntVariables, because the second instance of IntegerVariable is undocumented:
/**
* \ingroup A
*/
extern int VarInA;
/**
* \defgroup IntVariables Global integer variables
* @{
*/
/** an integer variable */

extern int IntegerVariable;
/**@}*/
....
/**
* \defgroup Variables Global variables
*/
/**@{*/
/** a variable in group A */

int VarInA;
int IntegerVariable;
/**@}*/
The \ref command can be used to refer to a group. The first argument of the \ref command should be group's label.
To use a custom link name, you can put the name of the links in double quotes after the label, as shown by the
following example
This is the \ref group_label "link" to this group.
The priorities of grouping definitions are (from highest to lowest): \ingroup, \defgroup, \addtogroup, \weakgroup.
The \weakgroup command is exactly like \addtogroup with a lower priority. It was added to allow ¨lazy¨ grouping
definitions: you can use commands with a higher priority in your .h files to define the hierarchy and \weakgroup in
.c files without having to duplicate the hierarchy exactly.
Example:
/** @defgroup group1 The First Group

* This is the first group
* @{
*/
/** @brief class C1 in group 1 */

class C1 {};
/** @brief class C2 in group 1 */

class C2 {};
/** function in group 1 */

void func() {}
/** @} */ // end of group1
/**
* @defgroup group2 The Second Group
* This is the second group
*/
/** @defgroup group3 The Third Group

* This is the third group
*/
/** @defgroup group4 The Fourth Group

* @ingroup group3
* Group 4 is a subgroup of group 3

7.2 Member Groups 45
*/
/**
* @ingroup group2
* @brief class C3 in group 2
*/
class C3 {};
/** @ingroup group2

* @brief class C4 in group 2
*/
class C4 {};
/** @ingroup group3

* @brief class C5 in @link group3 the third group@endlink.
*/
class C5 {};
/** @ingroup group1 group2 group3 group4

* namespace N1 is in four groups
* @sa @link group1 The first group@endlink, group2, group3, group4
*
* Also see @ref mypage2
*/
namespace N1 {};
/** @file
* @ingroup group3
* @brief this file in group 3
*/
/** @defgroup group5 The Fifth Group

* This is the fifth group
* @{
*/
/** @page mypage1 This is a section in group 5

* Text of the first section
*/
/** @page mypage2 This is another section in group 5

* Text of the second section
*/
/** @} */ // end of group5
/** @addtogroup group1

*
* More documentation for the first group.
* @{
*/
/** another function in group 1 */

void func2() {}
/** yet another function in group 1 */

void func3() {}
/** @} */ // end of group1
See Modules example for the corresponding LATEX documentation that is generated by doxygen.
7.2 Member Groups
If a compound (e.g. a class or file) has many members, it is often desired to group them together. Doxygen already
automatically groups things together on type and protection level, but maybe you feel that this is not enough or that
that default grouping is wrong. For instance, because you feel that members of different (syntactic) types belong to
the same (semantic) group.
A member group is defined by a
///@{
...
///@}
block or a

46 Grouping
/**@{*/
...
/**@}*/
block if you prefer C style comments. Note that the members of the group should be physically inside the member
group's body.
Before the opening marker of a block a separate comment block may be placed. This block should contain the
@name (or \name) command and is used to specify the header of the group. Optionally, the comment block may
also contain more detailed information about the group.
Nesting of member groups is not allowed.
If all members of a member group inside a class have the same type and protection level (for instance all are static
public members), then the whole member group is displayed as a subgroup of the type/protection level group (the
group is displayed as a subsection of the ¨Static Public Members¨ section for instance). If two or more members
have different types, then the group is put at the same level as the automatically generated groups. If you want
to force all member-groups of a class to be at the top level, you should put a \nosubgrouping command inside the
documentation of the class.
Example:
/** A class. Details */

class Memgrp_Test
{
public:
///@{
/** Same documentation for both members. Details */
void func1InGroup1();
///@}
/** Function without group. Details. */

void ungroupedFunction();
protected:
};
void Memgrp_Test::func1InGroup1() {}
/** @name Group2

* Description of group 2.
*/
///@{
/** Function 2 in group 2. Details. */
/** Function 1 in group 2. Details. */
///@}
/*! \file
* docs for this file
*/
//!@{
//! one description for all members of this group
//! (because DISTRIBUTE_GROUP_DOC is YES in the config file)
#define A 1
#define B 2
void glob_func();
//!@}
See Member Groups example for the corresponding LATEX documentation that is generated by doxygen.
Here Group1 is displayed as a subsection of the ¨Public Members¨. And Group2 is a separate section because it
contains members with different protection levels (i.e. public and protected).
7.3 Subpaging
Information can be grouped into pages using the \page and \mainpage commands. Normally, this results in a flat
list of pages, where the ¨main¨ page is the first in the list.

7.3 Subpaging 47
Instead of adding structure using the approach described in section modules it is often more natural and convenient
to add additional structure to the pages using the \subpage command.
For a page A the \subpage command adds a link to another page B and at the same time makes page B a subpage
of A. This has the effect of making two groups GA and GB, where GB is part of GA, page A is put in group GA, and
page B is put in group GB.

48 Grouping

Chapter 8
Including formulas
Doxygen allows you to put LATEX formulas in the output (this works only for the HTML, LATEX and RTF output. To be
able to include formulas (as images) in the HTML and RTF documentation, you will also need to have the following
tools installed
• latex: the LATEX compiler, needed to parse the formulas. To test I have used the teTeX 1.0 distribution.
• dvips: a tool to convert DVI files to PostScript files I have used version 5.92b from Radical Eye software
for testing.
• gs: the GhostScript interpreter for converting PostScript files to bitmaps. I have used Aladdin GhostScript
8.0 for testing.
For the HTML output there is also an alternative solution using MathJax which does not require the above tools.
If you enable USE_MATHJAX in the configuration then the latex formulas will be copied to the HTML äs is¨ and a
client side javascript will parse them and turn them into (interactive) images.
There are four ways to include formulas in the documentation.
1. Using in-text formulas that appear in the running text. These formulas should be put between a pair of \f$
commands, so
The distance between \f$(x_1,y_1)\f$ and \f$(x_2,y_2)\f$ is

\f$\sqrt{(x_2-x_1)^2+(y_2-y_1)^2}\f$.
results in:
p
The distance between (x1 , y1 ) and (x2 , y2 ) is (x2 − x1 )2 + (y2 − y1 )2 .
2. Using in-text formulas that appear in the running text, contrary to \f$ it will not explicitly open the math mode
in LATEX. These formulas should be put between \f( and \f) commands, so
The LaTeX and Tex logos are: \f(\LaTeX \f) and \f(\TeX \f).
results in:
The LaTeX and Tex logos are: LATEXand TEX.
3. Unnumbered displayed formulas that are centered on a separate line. These formulas should be put between
\f[ and \f] commands. An example:
\f[
|I_2|=\left| \int_{0}^T \psi(t)
\left\{
u(a,t)-
\int_{\gamma(t)}â
\frac{d\theta}{k(\theta,t)}
\int_{a}^\theta c(\xi)u_t(\xi,t)\,d\xi

50 Including formulas
\right\} dt
\right|
\f]
results in: Z T Z a
dθ
Z θ
|I2 | =
ψ(t) u(a,t) − c(ξ )ut (ξ ,t) dξ dt
0 γ(t) k(θ ,t) a
4. Formulas or other latex elements that are not in a math environment can be specified using \f{environment},
where environment is the name of the LATEX environment, the corresponding end command is \f}. Here is
an example for an equation array
\f{eqnarray*}{
g &=& \frac{Gm_2}{r^2} \\
&=& \frac{(6.673 \times 10^{-11}\,\mbox{m}^3\,\mbox{kg}^{-1}\,
\mbox{s}^{-2})(5.9736 \times 10^{24}\,\mbox{kg})}{(6371.01\,\mbox{km})^2} \\
&=& 9.82066032\,\mbox{m/s}^2
\f}
which results in:

Gm2
g =
r2
(6.673 × 10−11 m3 kg−1 s−2 )(5.9736 × 1024 kg)
=
(6371.01 km)2
= 9.82066032 m/s2
For the first and third commands one should make sure formulas contain valid commands in LATEX's math-mode.
The second command should valid text-mode commands that also work in math-mode when using USE_MATHJAX.
For the fourth command the section should contain valid command for the specific environment.
Warning
Currently, doxygen is not very fault tolerant in recovering from typos in formulas. It may be necessary to
remove the files formula.repository that are written to the html, rtf etc. directories to get rid of an
incorrect formula as well as the form_∗ files.
To have the possibility to define your own LATEX commands, for e.g. formula building blocks or consistent writing of
certain words, the configuration option FORMULA_MACROFILE can be used. to supply a file with LATEX commands.
This file can contain LATEX \newcommand and \renewcommand commands and they are included formulas
(image version and MathJax version) as well as in the generated LATEX output (for PDF generation).
The \newcommand (and \renewcommand) are restricted to a version without optional parameters so only the
following types are supported:
\newcommand{\cmd}{replacement}
\newcommand{\cmd}[nr]{replacement}
e.g.
\newcommand{\E}{\mathrm{E}}
\newcommand{\ccSum}[3]{\sum_{#1}^{#2}{#3}}

Chapter 9
Including tables
Doxygen supports two ways to put tables in the documentation.

The easiest is to use the Markdown format as shown in Markdown Extensions section Tables.
Although this format is easy to use and read, it is also rather limited. It supports only a simple grid of cells, while
each cell is a single line of plain text.
For more complex tables the HTML syntax can be used. Doxygen will process such tables and translate them to
the various output formats (at least for the formats that do support tables such as HTML and LATEX).
Note a table should at least contain 1 row (<tr>) and in case a <caption> is used the <caption> should
precede the first row.
Here is an example of a complex table:
<table>
<caption id="multi_row">Complex table</caption>
<tr><th>Column 1 <th>Column 2 <th>Column 3
<tr><td rowspan="2">cell row=1+2,col=1<td>cell row=1,col=2<td>cell row=1,col=3
<tr><td rowspan="2">cell row=2+3,col=2 <td>cell row=2,col=3
<tr><td>cell row=3,col=1 <td rowspan="2">cell row=3+4,col=3
<tr><td colspan="2">cell row=4,col=1+2
<tr><td>cell row=5,col=1 <td colspan="2">cell row=5,col=2+3
<tr><td colspan="2" rowspan="2">cell row=6+7,col=1+2 <td>cell row=6,col=3
<tr> <td>cell row=7,col=3
<tr><td>cell row=8,col=1 <td>cell row=8,col=2\n
<table>
<tr><td>Inner cell row=1,col=1<td>Inner cell row=1,col=2
<tr><td>Inner cell row=2,col=1<td>Inner cell row=2,col=2
</table>
<td>cell row=8,col=3
<ul>
<li>Item 1
<li>Item 2
</ul>
</table>
It has a caption, table heading, various row and column spans, a nested table as one of the cells, and a item list in
another cell.
Note that the end tags (like </td>) are left out in the example above. This is allowed, and in the HTML output
doxygen will add the end tags again.

52 Including tables
The output will look as follows:
Table 9.1: Complex table
Column 1 Column 2 Column 3

cell row=1,col=2 cell row=1,col=3
cell row=1+2,col=1
cell row=2,col=3
cell row=2+3,col=2
cell row=3,col=1
cell row=3+4,col=3
cell row=4,col=1+2
cell row=5,col=1 cell row=5,col=2+3
cell row=6,col=3
cell row=6+7,col=1+2
cell row=7,col=3
cell row=8,col=1 cell row=8,col=2 cell row=8,col=3
Inner cell row=1,col=1 Inner cell row=1,col=2
Inner cell row=2,col=1 Inner cell row=2,col=2 • Item 1
• Item 2
One can refer to the caption of the table using \ref using the caption's id as the label.

Chapter 10
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 HAVE_DOT to YES in the configuration file to let doxygen use it.
Doxygen uses the ¨dot¨ tool 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.
Warning: 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 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 \callgraph and section \hidecallgraph).
• if 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 \callergraph and section \hidecallergraph).
• If 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 DIR_GRAPH_MAX_DEPTH. Include
dependencies between the directories are shown as arrows.
Using a layout file you can determine which of the graphs are actually shown.
The options DOT_GRAPH_MAX_NODES and 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:

54 Graphs and diagrams
• 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 doxygen 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 üsage¨ 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>∗).
The elements in the directory dependency graphs have the following meaning:
• A box with a bold border indicates the directory that the directory dependency graph has been generated for.
• A box with a red solid border indicates a directory whose subdirectories are not shown in the graph (¨trun-
cated¨). To configure the depth of subdirectories that are shown in the graph see DIR_GRAPH_MAX_DEPTH.
• A box with a red dashed border indicates a truncated directory whose parent directories are not shown in
the graph either.
• A box with a dashed border other than red indicates that not all but at least one subdirectory are shown.
• A box with a light gray border indicates a directory with both of the following two attributes:
– Its parent directory is not shown.

55
– At least one subdirectory is shown.
• A box with no background color 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.
• An arrow between two boxes indicates an include dependency between two directories. The include depen-
dency 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).
Here are a couple of header files that together show the various diagrams that doxygen 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

56 Graphs and diagrams

Chapter 11
Preprocessing
Source files that are used as input to doxygen can be parsed by doxygen's built-in C-preprocessor.
By default doxygen does only partial preprocessing. That is, it evaluates conditional compilation statements (like
#if) and evaluates macro definitions, but it does not perform macro expansion.
So if you have the following code fragment
#define VERSION 200

#define CONST_STRING const char *
#if VERSION >= 200

static CONST_STRING version = "2.xx";
#else
#endif
Then by default doxygen will feed the following to its parser:
#define VERSION
#define CONST_STRING
You can disable all preprocessing by setting ENABLE_PREPROCESSING to NO in the configuration file. In the
case above doxygen will then read both statements, i.e.:

In case you want to expand the CONST_STRING macro, you should set the MACRO_EXPANSION tag in the
configuration file to YES. Then the result after preprocessing becomes:
#define VERSION
#define CONST_STRING
static const char * version = "2.xx";
Note that doxygen will now expand all macro definitions (recursively if needed). This is often too much. There-
fore, doxygen also allows you to expand only those defines that you explicitly specify. For this you have
to set the EXPAND_ONLY_PREDEF tag to YES and specify the macro definitions after the PREDEFINED or
EXPAND_AS_DEFINED tag.
A typically example where some help from the preprocessor is needed is when dealing with the language extension
from Microsoft: __declspec. The same goes for GNU's __attribute__ extension. Here is an example
function.

58 Preprocessing
extern "C" void __declspec(dllexport) ErrorMsg( String aMessage,...);
When nothing is done, doxygen will be confused and see __declspec as some sort of function. To help doxygen
one typically uses the following preprocessor settings:
ENABLE_PREPROCESSING = YES
MACRO_EXPANSION = YES
EXPAND_ONLY_PREDEF = YES
PREDEFINED = __declspec(x)=
This will make sure the __declspec(dllexport) is removed before doxygen parses the source code.
Similar settings can be used for removing __attribute__ expressions from the input:
PREDEFINED = __attribute__(x)=
For a more complex example, suppose you have the following obfuscated code fragment of an abstract base class
called IUnknown:
/*! A reference to an IID */

#ifdef __cplusplus
#define REFIID const IID &
#else
#define REFIID const IID *
#endif
/*! The IUnknown interface */

DECLARE_INTERFACE(IUnknown)
{
STDMETHOD(HRESULT,QueryInterface) (THIS_ REFIID iid, void **ppv) PURE;
STDMETHOD(ULONG,AddRef) (THIS) PURE;
STDMETHOD(ULONG,Release) (THIS) PURE;
};
without macro expansion doxygen will get confused, but we may not want to expand the REFIID macro, because
it is documented and the user that reads the documentation should use it when implementing the interface.
By setting the following in the configuration file:
ENABLE_PREPROCESSING =
YES
MACRO_EXPANSION =
YES
EXPAND_ONLY_PREDEF =
YES
PREDEFINED =
"DECLARE_INTERFACE(name)=class name" \
"STDMETHOD(result,name)=virtual result name" \
"PURE= = 0" \
THIS_= \
THIS= \
__cplusplus
we can make sure that the proper result is fed to doxygen's parser:
/*! A reference to an IID */

#define REFIID
/*! The IUnknown interface */

class IUnknown
{
virtual HRESULT QueryInterface ( REFIID iid, void **ppv) = 0;
virtual ULONG AddRef () = 0;
virtual ULONG Release () = 0;
};

59
Note that the PREDEFINED tag accepts function like macro definitions (like DECLARE_INTERFACE ), normal
macro substitutions (like PURE and THIS) and plain defines (like __cplusplus).
Note also that preprocessor definitions that are normally defined automatically by the preprocessor (like __←-
cplusplus), have to be defined by hand with doxygen's parser (this is done because these defines are often
platform/compiler specific).
In some cases you may want to substitute a macro name or function by something else without exposing the result
to further macro substitution. You can do this but using the := operator instead of =
As an example suppose we have the following piece of code:
#define QList QListT

class QListT
{
};
Then the only way to get doxygen interpret this as a class definition for class QList is to define:
PREDEFINED = QListT:=QList
Here is an example provided by Valter Minute and Reyes Ponce that helps doxygen to wade through the boilerplate
code in Microsoft's ATL & MFC libraries:
PREDEFINED = "DECLARE_INTERFACE(name)=class name" \

"STDMETHOD(result,name)=virtual result name" \
"PURE= = 0" \
THIS_= \
THIS= \
DECLARE_REGISTRY_RESOURCEID=// \
DECLARE_PROTECT_FINAL_CONSTRUCT=// \
"DECLARE_AGGREGATABLE(Class)= " \
"DECLARE_REGISTRY_RESOURCEID(Id)= " \
DECLARE_MESSAGE_MAP= \
BEGIN_MESSAGE_MAP=/* \
END_MESSAGE_MAP=*/// \
BEGIN_COM_MAP=/* \
END_COM_MAP=*/// \
BEGIN_PROP_MAP=/* \
END_PROP_MAP=*/// \
BEGIN_MSG_MAP=/* \
END_MSG_MAP=*/// \
BEGIN_PROPERTY_MAP=/* \
END_PROPERTY_MAP=*/// \
BEGIN_OBJECT_MAP=/* \
END_OBJECT_MAP()=*/// \
DECLARE_VIEW_STATUS=// \
"STDMETHOD(a)=HRESULT a" \
"ATL_NO_VTABLE= " \
"__declspec(a)= " \
BEGIN_CONNECTION_POINT_MAP=/* \
END_CONNECTION_POINT_MAP=*/// \
"DECLARE_DYNAMIC(class)= " \
"IMPLEMENT_DYNAMIC(class1, class2)= " \
"DECLARE_DYNCREATE(class)= " \
"IMPLEMENT_DYNCREATE(class1, class2)= " \
"IMPLEMENT_SERIAL(class1, class2, class3)= " \
"DECLARE_MESSAGE_MAP()= " \
TRY=try \
"CATCH_ALL(e)= catch(...)" \
END_CATCH_ALL= \
"THROW_LAST()= throw"\
"RUNTIME_CLASS(class)=class" \
"MAKEINTRESOURCE(nId)=nId" \
"IMPLEMENT_REGISTER(v, w, x, y, z)= " \
"ASSERT(x)=assert(x)" \
"ASSERT_VALID(x)=assert(x)" \
"TRACE0(x)=printf(x)" \
"OS_ERR(A,B)={ #A, B }" \

60 Preprocessing
__cplusplus \
"DECLARE_OLECREATE(class)= " \
"BEGIN_DISPATCH_MAP(class1, class2)= " \
"BEGIN_INTERFACE_MAP(class1, class2)= " \
"INTERFACE_PART(class, id, name)= " \
"END_INTERFACE_MAP()=" \
"DISP_FUNCTION(class, name, function, result, id)=" \
"END_DISPATCH_MAP()=" \
"IMPLEMENT_OLECREATE2(class, name, id1, id2, id3, id4,\
id5, id6, id7, id8, id9, id10, id11)="
As you can see doxygen's preprocessor is quite powerful, but if you want even more flexibility you can al-
ways write an input filter and specify it after the INPUT_FILTER tag or the FILTER_PATTERNS tag (or the
FILTER_SOURCE_PATTERNS tag).
If you are unsure what the effect of the filter will be you can run doxygen as follows: doxygen -d
filteroutput.
If you are unsure what the effect of doxygen's preprocessing will be you can run doxygen as follows:
doxygen -d Preprocessor
or when the line numbers are not wanted:
doxygen -d Preprocessor -d NoLineno
This will instruct doxygen to dump the input sources to standard output after preprocessing has been done (Hint:
set QUIET = YES and WARNINGS = NO in the configuration file to disable any other output).
Note preprocessing is not done for all languages. Preprocessing is enabled for files that use the ¨C¨ scanner (with
the exception of 'java', 'd' and 'php'), Fortran files (only in case the extension contains at least one upper case
character) and vhdl files.

Chapter 12
Automatic link generation
12.1 Links to web pages and mail addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

12.2 Links to classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
12.3 Links to files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
12.4 Links to functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
12.5 Links to other members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
12.6 typedefs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Most documentation systems have special ‘see also’ sections where links to other pieces of documentation can be
inserted. Although doxygen also has a command to start such a section (See section \sa), it does allow you to
put these kind of links anywhere in the documentation. For LATEX documentation a reference to the page number
is written instead of a link. Furthermore, the index at the end of the document can be used to quickly find the
documentation of a member, class, namespace or file. For man pages no reference information is generated.
The next sections show how to generate links to the various documented entities in a source file.
12.1 Links to web pages and mail addresses
Doxygen will automatically replace any URLs and mail addresses found in the documentation by links (in HTML).
To manually specify link text, use the HTML 'a' tag:
<a href="linkURL">link text</a>
which will be automatically translated to other output formats by doxygen.
12.2 Links to classes
All words in the documentation that correspond to a documented class and contain at least one non-lower case
character will automatically be replaced by a link to the page containing the documentation of the class. If you want
to prevent that a word that corresponds to a documented class is replaced by a link you should put a % in front of
the word. To link to an all lower case symbol, use \ref.
12.3 Links to files
All words that contain a dot (.) that is not the last character in the word are considered to be file names. If the word
is indeed the name of a documented input file, a link will automatically be created to the documentation of that file.

62 Automatic link generation
12.4 Links to functions
Links to functions are created if one of the following patterns is encountered:
1. <functionName>¨(¨<argument-list>¨)¨
2. <functionName>¨()¨
3. ¨::¨<functionName>
4. (<className>¨::¨)n <functionName>¨(¨<argument-list>¨)¨
5. (<className>¨::¨)n <functionName>¨(¨<argument-list>¨)¨<modifiers>
6. (<className>¨::¨)n <functionName>¨()¨
7. (<className>¨::¨)n <functionName>
where n>0.
Note 1:
Function arguments should be specified with correct types, i.e. 'fun(const std::string&,bool)' or '()' to match
any prototype.
Note 2:
Member function modifiers (like 'const' and 'volatile') are required to identify the target, i.e. 'func(int) const' and
'func(int)' target different member functions.
Note 3:
For Javadoc compatibility a # may be used instead of a :: in the patterns above.
Note 4:
In the documentation of a class containing a member foo, a reference to a global variable is made using ¨::foo¨,
whereas #foo will link to the member.
For non overloaded members the argument list may be omitted.

If a function is overloaded and no matching argument list is specified (i.e. pattern 2 or 6 is used), a link will be
created to the documentation of one of the overloaded members.
For member functions the class scope (as used in patterns 4 to 7) may be omitted, if:
1. The pattern points to a documented member that belongs to the same class as the documentation block that
contains the pattern.
2. The class that corresponds to the documentation blocks that contains the pattern has a base class that
contains a documented member that matches the pattern.
12.5 Links to other members
All of these entities can be linked to in the same way as described in the previous section. For sake of clarity it is
advised to only use patterns 3 and 7 in this case.

12.5 Links to other members 63
Example:
/*! \file autolink.cpp

Testing automatic link generation.
A link to a member of the Autolink_Test class: Autolink_Test::member,
More specific links to the each of the overloaded members:

Autolink_Test::member(int) and Autolink_Test#member(int,int)
A link to a protected member variable of Autolink_Test: Autolink_Test#var,
A link to the global enumeration type #GlobEnum.
A link to the define #ABS(x).
A link to the destructor of the Autolink_Test class: Autolink_Test::~Autolink_Test,
A link to the typedef ::B.
A link to the enumeration type Autolink_Test::EType
A link to some enumeration values Autolink_Test::Val1 and ::GVal2

*/
/*!
Since this documentation block belongs to the class Autolink_Test no link to
Autolink_Test is generated.
Two ways to link to a constructor are: #Autolink_Test and Autolink_Test().
Links to the destructor are: #~Autolink_Test and ~Autolink_Test().
A link to a member in this class: member().
More specific links to the each of the overloaded members:

member(int) and member(int,int).
A link to the variable #var.
A link to the global typedef ::B.
A link to the global enumeration type #GlobEnum.
A link to the define ABS(x).
A link to a variable \link #var using another text\endlink as a link.
A link to the enumeration type #EType.
A link to some enumeration values: \link Autolink_Test::Val1 Val1 \endlink and ::GVal1.
And last but not least a link to a file: autolink.cpp.
\sa Inside a see also section any word is checked, so EType,

Val1, GVal1, ~Autolink_Test and member will be replaced by links in HTML.
*/
class Autolink_Test
{
public:
Autolink_Test(); //!< constructor
~Autolink_Test(); //!< destructor
void member(int); /**< A member function. Details. */
void member(int,int); /**< An overloaded member function. Details */
/** An enum type. More details */

enum EType {
Val1, /**< enum value 1 */
Val2 /**< enum value 2 */
};
protected:
int var; /**< A member variable */
};
/*! details. */
Autolink_Test::Autolink_Test() { }
/*! details. */
Autolink_Test::~Autolink_Test() { }
/*! A global variable. */

int globVar;
/*! A global enum. */

enum GlobEnum {

64 Automatic link generation
GVal1, /*!< global enum value 1 */

GVal2 /*!< global enum value 2 */
};
/*!
* A macro definition.
*/
#define ABS(x) (((x)>0)?(x):-(x))
typedef Autolink_Test B;
/*! \fn typedef Autolink_Test B

* A type definition.
*/
See Autolink example for the corresponding LATEX documentation that is generated by doxygen.
12.6 typedefs
Typedefs that involve classes, structs and unions, like
typedef struct StructName TypeName
create an alias for StructName, so links will be generated to StructName, when either StructName itself or Type←-
Name is encountered.
Example:
/*! \file restypedef.cpp

* An example of resolving typedefs.
*/
/*! \struct CoordStruct

* A coordinate pair.
*/
struct CoordStruct
{
/*! The x coordinate */
float x;
/*! The y coordinate */
float y;
};
/*! Creates a type name for CoordStruct */

typedef CoordStruct Coord;
/*!
* This function returns the addition of \a c1 and \a c2, i.e:
* (c1.x+c2.x,c1.y+c2.y)
*/
Coord add(Coord c1,Coord c2)
{
}
See Typedef example for the corresponding LATEX documentation that is generated by doxygen.

Chapter 13
Output Formats
The following output formats are directly supported by doxygen:
HTML Generated if GENERATE_HTML is set to YES in the configuration file.
LATEX Generated if GENERATE_LATEX is set to YES in the configuration file.
Man pages Generated if GENERATE_MAN is set to YES in the configuration file.
RTF Generated if GENERATE_RTF is set to YES in the configuration file.

Note that the RTF output probably only looks nice with Microsoft's Word. If you have success with other
programs, please let me know.
XML Generated if GENERATE_XML is set to YES in the configuration file.
DocBook Generated if GENERATE_DOCBOOK is set to YES in the configuration file.
The following output formats are indirectly supported by doxygen:
Compiled HTML Help (a.k.a. Windows 98 help) Generated by Microsoft's HTML Help workshop from the HTML
output if GENERATE_HTMLHELP is set to YES.
Qt Compressed Help (.qch) Generated by Qt's qhelpgenerator tool from the HTML output if GENERATE_QHP is
set to YES.
Eclipse Help Generated from HTML with a special index file that is generated when GENERATE_ECLIPSEHELP
is set to YES.
XCode DocSets Compiled from HTML with a special index file that is generated when GENERATE_DOCSET is
set to YES.
PostScript Generated from the LATEX output by running make ps in the output directory. For the best results
PDF_HYPERLINKS should be set to NO.
PDF Generated from the LATEX output by running make pdf in the output directory. To improve the PDF out-
put, you typically would want to enable the use of pdflatex by setting USE_PDFLATEX to YES in the
configuration file. In order to get hyperlinks in the PDF file you also need to enable PDF_HYPERLINKS.

66 Output Formats

Chapter 14
Searching
Doxygen indexes your source code in various ways to make it easier to navigate and find what you are looking for.
There are also situations however where you want to search for something by keyword rather than browse for it.
HTML browsers by default have no search capabilities that work across multiple pages, so either doxygen or external
tools need to help to facilitate this feature.
Doxygen has 7 different ways to add searching to the HTML output, each of which has its own advantages and
disadvantages:
1. Client side searching
The easiest way to enable searching is to enable the built-in client side search engine. This engine is implemented
using JavaScript and DHTML only and runs entirely on the clients browser. So no additional tooling is required to
make it work.
To enable it set SEARCHENGINE to YES in the configuration file and make sure SERVER_BASED_SEARCH is
set to NO.
An additional advantage of this method is that it provides live searching, i.e. the search results are presented and
adapted as you type.
This method also has its drawbacks: it is limited to searching for symbols only. It does not provide full text search
capabilities and it does not scale well to very large projects (then searching becomes very slow). Furthermore the
searching is done from the beginning of the indexed items, so when having the available items A_STRING, AA←-
_STRING and STRING and typing in the search box A it will find A_STRING and AA_STRING, but when typing
e.g. STR it will only find STRING and not A_STRING.
2. Server side searching
If you plan to put the HTML documentation on a web server, and that web server has the capability to process PHP
code, then you can also use doxygen's built-in server side search engine.
To enable this set both SEARCHENGINE and SERVER_BASED_SEARCH to YES in the configuration file and set
EXTERNAL_SEARCH to NO.
Advantages over the client side search engine are that it provides full text search and it scales well to medium side
projects.
Disadvantages are that it does not work locally (i.e. using a ¨file://¨ URL) and that it does not provide live search
capabilities.
Note
In the future this option will probably be replaced by the next search option.

68 Searching
3. Server side searching with external indexing
With release 1.8.3 of doxygen, another server based search option has been added. With this option doxygen
generates the raw data that can be searched and leaves it up to external tools to do the indexing and searching,
meaning that you could use your own indexer and search engine of choice. To make life easier doxygen ships with
an example indexer (doxyindexer) and search engine (doxysearch.cgi) based on the Xapian open source search
engine library.
To enable this search method set SEARCHENGINE, SERVER_BASED_SEARCH and EXTERNAL_SEARCH all to
YES.
See External Indexing and Searching for configuration details.
Advantages over option 2 are that this method (potentially) scales to very large projects. It is also possible to
combine multiple doxygen projects and external data into one search index. The way the interaction with the search
engine is done, makes it possible to search from local HTML pages. Also the search results have better ranking
and show context information (if available).
Disadvantages are that is requires a web server that can execute a CGI binary, and an additional indexing step after
running doxygen.
4. Windows Compiled HTML Help
If you are running doxygen on Windows, then you can make a compiled HTML Help file (.chm) out of the HTML files
produced by doxygen. This is a single file containing all HTML files and it also includes a search index. There are
viewers for this format on many platforms, and Windows even supports it natively.
To enable this set GENERATE_HTMLHELP to YES in the configuration file. To let doxygen compile the HTML
Help file for you, you also need to specify the path to the HTML compiler (hhc.exe) using the HHC_LOCATION
configuration option and the name of the resulting CHM file using CHM_FILE.
An advantage of this method is that the result is a single file that can easily be distributed. It also provides full text
search.
Disadvantages are that compiling the CHM file only works on Windows and requires Microsoft's HTML compiler,
which is not very actively supported by Microsoft. Although the tool works fine for most people, it can sometimes
crash for no apparent reason (how typical).
5. Mac OS X Doc Sets
If you are running doxygen on Mac OS X 10.5 or higher, then you can make a ¨doc set¨ out of the HTML files pro-
duced by doxygen. A doc set consists of a single directory with a special structure containing the HTML files along
with a precompiled search index. A doc set can be embedded in Xcode (the integrated development environment
provided by Apple).
To enable the creation of doc sets set GENERATE_DOCSET to YES in the configuration file. There are a couple
of other doc set related options you may want to set. After doxygen has finished you will find a Makefile in the
HTML output directory. Running ¨make install¨ on this Makefile will compile and install the doc set. See this
article for more info.
Advantage of this method is that it nicely integrates with the Xcode development environment, allowing for instance
to click on an identifier in the editor and jump to the corresponding section in the doxygen documentation.
Disadvantage is that it only works in combination with Xcode on MacOSX.
6. Qt Compressed Help
If you develop for or want to install the Qt application framework, you will get an application called Qt
assistant. This is a help viewer for Qt Compressed Help files (.qch).

14.1 External Indexing and Searching 69
To enable this feature set GENERATE_QHP to YES. You also need to fill in the other Qt help related options, such
as QHP_NAMESPACE, QHG_LOCATION, QHP_VIRTUAL_FOLDER. See this article for more info.
Feature wise the Qt compressed help feature is comparable with the CHM output, with the additional advantage
that compiling the QCH file is not limited to Windows.
Disadvantage is that it requires setting up a Qt 4.5 (or better) for each user, or distributing the Qt help assistant
along with the documentation, which is complicated by the fact that it is not available as a separate package at this
moment.
7. Eclipse Help Plugin
If you use eclipse, you can embed the documentation generated by doxygen as a help plugin. It will then appear
as a topic in the help browser that can be started from ¨Help contents¨ in the Help menu. Eclipse will generate a
search index for the documentation when you first search for a keyword.
To enable the help plugin set GENERATE_ECLIPSEHELP to YES, and define a unique identifier for your project via
ECLIPSE_DOC_ID, i.e.:
GENERATE_ECLIPSEHELP = YES
ECLIPSE_DOC_ID = com.yourcompany.yourproject
then create the com.yourcompany.yourproject directory (so with the same name as the value of
ECLIPSE_DOC_ID) in the plugin directory of eclipse and after doxygen completes copy to contents of the
help output directory to the com.yourcompany.yourproject directory. Then restart eclipse to make let it
find the new plugin.
The eclipse help plugin provides similar functionality as the Qt compressed help or CHM output, but it does require
that Eclipse is installed and running.
14.1 External Indexing and Searching
14.1.1 Introduction
With release 1.8.3, doxygen provides the ability to search through HTML using an external indexing tool and search
engine. This has several advantages:
• For large projects it can have significant performance advantages over doxygen's built-in search engine, as
doxygen uses a rather simple indexing algorithm.
• It allows combining the search data of multiple projects into one index, allowing a global search across multiple
doxygen projects.
• It allows adding additional data to the search index, i.e. other web pages not produced by doxygen.
• The search engine needs to run on a web server, but clients can still browse the web pages locally.
To avoid that everyone has to start writing their own indexer and search engine, doxygen provides an example tool
for each action: doxyindexer for indexing the data and doxysearch.cgi for searching through the index.
The data flow is shown in the following diagram:

70 Searching
doxygen
writes
searchdata.xml
reads
doxyindexer
writes
doxysearch.db
reads
doxysearch.cgi
get results query
HTML page
in browser
Figure 14.1: External Search Data Flow
• doxygen produces the raw search data
• doxyindexer indexes the data into a search database doxysearch.db
• when a user performs a search from a doxygen generated HTML page, the CGI binary doxysearch.cgi
will be invoked.
• the doxysearch.cgi tool will perform a query on the database and return the results.
• The browser will show the search results.
14.1.2 Configuring
The first step is to make the search engine available via a web server. If you use doxysearch.cgi this means
making the CGI binary available from the web server (i.e. be able to run it from a browser via an URL starting with
http:)
How to setup a web server is outside the scope of this document, but if you for instance have Apache installed,
you could simply copy the doxysearch.cgi file from doxygen's bin directory to the cgi-bin directory of the
Apache web server. Read the apache documentation for details.
To test if doxysearch.cgi is accessible start your web browser and point to URL to the binary and add ?test
at the end
http://yoursite.com/path/to/cgi/doxysearch.cgi?test
You should get the following message:
Test failed: cannot find search index doxysearch.db
If you use Internet Explorer you may be prompted to download a file, which will then contain this message.

Since we didn't create or install a doxysearch.db it is OK for the test to fail for this reason. How to correct this is
discussed in the next section.
Before continuing with the next section add the above URL (without the ?test part) to the SEARCHENGINE_URL
tag in doxygen's configuration file:
SEARCHENGINE_URL = http://yoursite.com/path/to/cgi/doxysearch.cgi
Single project index
To use the external search option, make sure the following options are enabled in doxygen's configuration file:
SEARCHENGINE = YES
SERVER_BASED_SEARCH = YES
EXTERNAL_SEARCH = YES
This will make doxygen generate a file called searchdata.xml in the output directory (configured with
OUTPUT_DIRECTORY). You can change the file name (and location) with the SEARCHDATA_FILE option.
The next step is to put the raw search data into an index for efficient searching. You can use doxyindexer for
this. Simply run it from the command line:
doxyindexer searchdata.xml
This will create a directory called doxysearch.db with some files in it. By default the directory will be created at
the location from which doxyindexer was started, but you can change the directory using the -o option.
Copy the doxysearch.db directory to the same directory as where the doxysearch.cgi is located and
rerun the browser test by pointing the browser to
http://yoursite.com/path/to/cgi/doxysearch.cgi?test
You should now get the following message:
Test successful.
Now you should be able to search for words and symbols from the HTML output.
Multi project index
In case you have more than one doxygen project and these projects are related, it may be desirable to allow
searching for words in all projects from within the documentation of any of the projects.
To make this possible all that is needed is to combine the search data for all projects into a single index, e.g. for two
projects A and B for which the searchdata.xml is generated in directories project_A and project_B run:
doxyindexer project_A/searchdata.xml project_B/searchdata.xml
and then copy the resulting doxysearch.db to the directory where also doxysearch.cgi is located.
The searchdata.xml file doesn't contain any absolute paths or links, so how can the search results from
multiple projects be linked back to the right documentation set? This is where the EXTERNAL_SEARCH_ID and
EXTRA_SEARCH_MAPPINGS options come into play.
To be able to identify the different projects, one needs to set a unique ID using EXTERNAL_SEARCH_ID for each
project.
To link the search results to the right project, you need to define a mapping per project using the
EXTRA_SEARCH_MAPPINGS tag. With this option to can define the mapping from IDs of other projects to
the (relative) location of documentation of those projects.
So for projects A and B the relevant part of the configuration file could look as follows:

72 Searching
project_A/Doxyfile
------------------
EXTERNAL_SEARCH_ID = A
EXTRA_SEARCH_MAPPINGS = B=../../project_B/html
for project A and for project B
project_B/Doxyfile
------------------
EXTERNAL_SEARCH_ID = B
EXTRA_SEARCH_MAPPINGS = A=../../project_A/html
with these settings, projects A and B can share the same search database, and the search results will link to the
right documentation set.
14.1.3 Updating the index
When you modify the source code, you should re-run doxygen to get up to date documentation again. When using
external searching you also need to update the search index by re-running doxyindexer. You could wrap the
call to doxygen and doxyindexer together in a script to make this process easier.
14.1.4 Programming interface
Previous sections have assumed you use the tools doxyindexer and doxysearch.cgi to do the indexing
and searching, but you could also write your own index and search tools if you like.
For this 3 interfaces are important
• The format of the input for the index tool.
• The format of the input for the search engine.
• The format of the output of search engine.
The next subsections describe these interfaces in more detail.
Indexer input format
The search data produced by doxygen follows the Solr XML index message format.
The input for the indexer is an XML file, which consists of one <add> tag containing multiple <doc> tags, which
in turn contain multiple <field> tags.
Here is an example of one doc node, which contains the search data and meta data for one method:
<add>
...
<doc>
<field name="type">function</field>
<field name="name">QXmlReader::setDTDHandler</field>
<field name="args">(QXmlDTDHandler *handler)=0</field>
<field name="tag">qtools.tag</field>
<field name="url">de/df6/class_q_xml_reader.html#a0b24b1fe26a4c32a8032d68ee14d5dba</field>
<field name="keywords">setDTDHandler QXmlReader::setDTDHandler QXmlReader</field>
<field name="text">Sets the DTD handler to handler DTDHandler()</field>
</doc>
...
</add>
Each field has a name. The following field names are supported:

• type: the type of the search entry; can be one of: source, function, slot, signal, variable, typedef, enum,
enumvalue, property, event, related, friend, define, file, namespace, group, package, page, dir
• name: the name of the search entry; for a method this is the qualified name of the method, for a class it is the
name of the class, etc.
• args: the parameter list (in case of functions or methods)
• tag: the name of the tag file used for this project.
• url: the (relative) URL to the HTML documentation for this entry.
• keywords: important words that are representative for the entry. When searching for such keyword, this entry
should get a higher rank in the search results.
• text: the documentation associated with the item. Note that only words are present, no markup.
Note
Due to the potentially large size of the XML file, it is recommended to use a SAX based parser to
process it.
Search URL format
When the search engine is invoked from a doxygen generated HTML page, a number of parameters are passed to
via the query string.
The following fields are passed:
• q: the query text as entered by the user
• n: the number of search results requested.
• p: the number of search page for which to return the results. Each page has n values.
• cb: the name of the callback function, used for JSON with padding, see the next section.
From the complete list of search results, the range [n∗p - n∗(p+1)-1] should be returned.
Here is an example of how a query looks like.
http://yoursite.com/path/to/cgi/doxysearch.cgi?q=list&n=20&p=1&cb=dummy
It represents a query for the word 'list' (q=list) requesting 20 search results (n=20), starting with the result
number 20 (p=1) and using callback 'dummy' (cb=dummy):
Note
The values are URL encoded so they have to be decoded before they can be used.
Search results format
When invoking the search engine as shown in the previous subsection, it should reply with the results. The format
of the reply is JSON with padding, which is basically a javascript struct wrapped in a function call. The name
of function should be the name of the callback (as passed with the cb field in the query).
With the example query as shown the previous subsection the main structure of the reply should look as follows:

74 Searching
dummy({
"hits":179,
"first":20,
"count":20,
"page":1,
"pages":9,
"query": "list",
"items":[
...
]})
The fields have the following meaning:
• hits: the total number of search results (could be more than was requested).
• first: the index of first result returned: min(n ∗ p, hits).
• count: the actual number of results returned: min(n, hits − first)
• page: the page number of the result: p

l m
• pages: the total number of pages: hits .
n
• items: an array containing the search data per result.
Here is an example of how the element of the items array should look like:
{"type": "function",
"name": "QDir::entryInfoList(const QString &nameFilter, int filterSpec=DefaultFilter, int sortSpec=DefaultSor
"tag": "qtools.tag",
"url": "d5/d8d/class_q_dir.html#a9439ea6b331957f38dbad981c4d050ef",
"fragments":[
"Returns a <span class=\"hl\">list</span> of QFileInfo objects for all files and directories...",
"... pointer to a QFileInfoList The <span class=\"hl\">list</span> is owned by the QDir object...",
"... to keep the entries of the <span class=\"hl\">list</span> after a subsequent call to this..."
]
},
The fields for such an item have the following meaning:
• type: the type of the item, as found in the field with name ¨type¨ in the raw search data.
• name: the name of the item, including the parameter list, as found in the fields with name ¨name¨ and ärgs¨
in the raw search data.
• tag: the name of the tag file, as found in the field with name ¨tag¨ in the raw search data.
• url: the name of the (relative) URL to the documentation, as found in the field with name ürl¨ in the raw search
data.
• ¨fragments¨: an array with 0 or more fragments of text containing words that have been search for. These
words should be wrapped in <span class=¨hl¨> and </span> tags to highlight them in the output.

Chapter 15
Customizing the output
15.1 Minor Tweaks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

15.1.1 Overall Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
15.1.2 Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
15.1.3 Dynamic Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
15.1.4 Header, Footer, and Stylesheet changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
15.2 Changing the layout of pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
15.3 Using the XML output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Doxygen provides various levels of customization. The section Minor Tweaks discusses what to do if you want to
do minor tweaking to the look and feel of the output. The section Layout show how to reorder and hide certain
information on a page. The section XML output show how to generate whatever output you want based on the XML
output produced by doxygen.
15.1 Minor Tweaks
The next subsections describe some aspects that can be tweaked with little effort.
15.1.1 Overall Color
To change the overall color of the HTML output doxygen provides three options
• HTML_COLORSTYLE_HUE
• HTML_COLORSTYLE_SAT
• HTML_COLORSTYLE_GAMMA
to change the hue, saturation, and gamma correction of the colors respectively.
For your convenience the GUI frontend Doxywizard has a control that allows you to see the effect of changing the
values of these options on the output in real time.
15.1.2 Navigation
By default doxygen shows navigation tabs on top of every HTML page, corresponding with the following settings:
• DISABLE_INDEX = NO

76 Customizing the output
• GENERATE_TREEVIEW = NO
you can switch to an interactive navigation tree as sidebar using
• DISABLE_INDEX = YES
• GENERATE_TREEVIEW = YES
• FULL_SIDEBAR = NO
you can also make the content span the title area of the screen using
• FULL_SIDEBAR = YES

15.1 Minor Tweaks 77
or even have both forms of navigation:
• DISABLE_INDEX = NO
if you already use an external index (i.e. have one of the following options enabled GENERATE_HTMLHELP,
GENERATE_ECLIPSEHELP, GENERATE_QHP, or GENERATE_DOCSET) then you can also disable all indices,
like so:
• GENERATE_TREEVIEW = NO
15.1.3 Dynamic Content
To make the HTML output more interactive, doxygen provides a number of options that are disabled by default:
• enabling HTML_DYNAMIC_SECTIONS will make doxygen hide certain content (like graphs) in the HTML by
default, and let the reader expand these sections on request.
• enabling HAVE_DOT along with INTERACTIVE_SVG while setting DOT_IMAGE_FORMAT to svg, will make
doxygen produce SVG images that will allow the user to zoom and pan (this only happens when the size of
the images exceeds a certain size).
15.1.4 Header, Footer, and Stylesheet changes
To tweak things like fonts or colors, margins, or other look & feel aspects of the HTML output in detail, you can
create a different cascading style sheet. You can also let doxygen use a custom header and footer for

each HTML page it generates, for instance to make the output conform to the style used on the rest of your web
site.
To do this first run doxygen as follows:
doxygen -w html header.html footer.html customdoxygen.css
This will create 3 files:
• header.html is a HTML fragment which doxygen normally uses to start a HTML page. Note that the fragment
ends with a body tag and that is contains a couple of commands of the form $word. These will be replaced
by doxygen on the fly.
• footer.html is a HTML fragment which doxygen normally uses to end a HTML page. Also here special com-
mands can be used. This file contain the link to www.doxygen.org and the body and html end tags.
• customdoxygen.css is the default cascading style sheet used by doxygen. It is recommended only to look
into this file and overrule some settings you like by putting them in a separate stylesheets and referencing
those extra files via HTML_EXTRA_STYLESHEET.
You should edit these files and then reference them from the configuration file.
• HTML_HEADER = header.html
• HTML_FOOTER = footer.html
• HTML_EXTRA_STYLESHEET = my_customdoxygen.css
Note
it is not longer recommended to use HTML_STYLESHEET, as it make it difficult to upgrade to a newer version
of doxygen. Use HTML_EXTRA_STYLESHEET instead.
See the documentation of the HTML_HEADER tag for more information about the possible meta commands you
can use inside your custom header.
Note
You should not put the style sheet in the HTML output directory. Treat it as a source file. Doxygen will copy it
for you.
If you use images or other external content in a custom header you need to make sure these end up in the
HTML output directory yourself, for instance by writing a script that runs doxygen can then copies the images
to the output.
Warning
The structure of headers and footers may change after upgrading to a newer version of doxygen, so if you are
using a custom header or footer, it might not produce valid output anymore after upgrading.
15.2 Changing the layout of pages
In some cases you may want to change the way the output is structured. A different style sheet or custom headers
and footers do not help in such case.
The solution doxygen provides is a layout file, which you can modify and doxygen will use to control what information
is presented, in which order, and to some extent also how information is presented. The layout file is an XML file.
The default layout can be generated by doxygen using the following command:

15.2 Changing the layout of pages 79
doxygen -l
optionally the name of the layout file can be specified, if omitted DoxygenLayout.xml will be used.
The next step is to mention the layout file in the configuration file
LAYOUT_FILE = DoxygenLayout.xml
To change the layout all you need to do is edit the layout file.
The toplevel structure of the file looks as follows:
<doxygenlayout version="1.0">
<navindex>
...
</navindex>
<class>
...
</class>
<namespace>
...
</namespace>
<concept>
...
</concept>
<file>
...
</file>
<group>
...
</group>
<directory>
...
</directory>
</doxygenlayout>
The root element of the XML file is doxygenlayout, it has an attribute named version, which will be used in
the future to cope with changes that are not backward compatible.
The first section, identified by the navindex element, represents the layout of the navigation tabs displayed
at the top of each HTML page. At the same time it also controls the items in the navigation tree in case
GENERATE_TREEVIEW is enabled. Each tab is represented by a tab element in the XML file.
You can hide tabs by setting the visible attribute to no. You can also override the default title of a tab by
specifying it as the value of the title attribute. If the title field is the empty string (the default) then doxygen will
fill in an appropriate language specific title.
You can reorder the tabs by moving the tab elements in the XML file within the navindex element and even
change the tree structure. Do not change the value of the type attribute however. Only a fixed set of types are
supported, each representing a link to a specific index.
You can also add custom tabs using a type with name üser¨. Here is an example that shows how to add a tab with
title ¨Google¨ pointing to www.google.com:
<navindex>
...
<tab type="user" url="http://www.google.com" title="Google"/>
...
</navindex>
The url field can also be a relative URL. If the URL starts with @ref the link will point to a documented entities,
such as a class, a function, a group, or a related page. Suppose we have defined a page using @page with label
mypage, then a tab with label ¨My Page¨ to this page would look as follows:
<navindex>
...
<tab type="user" url="@ref mypage" title="My Page"/>
...
</navindex>

You can also group tabs together in a custom group using a tab with type üsergroup¨. The following example puts
the above tabs in a user defined group with title ¨My Group¨:
<navindex>
...
<tab type="usergroup" title="My Group">
<tab type="user" url="http://www.google.com" title="Google"/>
<tab type="user" url="@ref mypage" title="My Page"/>
</tab>
...
</navindex>
Groups can be nested to form a hierarchy.

By default a usergroup entry in the navigation tree is a link to a landing page with the contents of the group. You
can link to a different page using the url attribute just like you can for the <tab> element and prevent any link
using url=¨[none]¨, i.e.
<tab type="usergroup" title="Group without link" url="[none]">

...
</tab>
The elements after navindex represent the layout of the different pages generated by doxygen:
• The class element represents the layout of all pages generated for documented classes, structs, unions,
and interfaces.
• The namespace element represents the layout of all pages generated for documented namespaces (and
also Java packages).
• The concept element represents the layout of all pages generated for documented concepts.
• The file element represents the layout of all pages generated for documented files.
• The group element represents the layout of all pages generated for documented groups (or modules).
• The directory element represents the layout of all pages generated for documented directories.
Each XML element within one of the above page elements represents a certain piece of information. Some pieces
can appear in each type of page, others are specific for a certain type of page. Doxygen will list the pieces in the
order in which they appear in the XML file.
The following generic elements are possible for each page:
briefdescription Represents the brief description on a page.

detaileddescription Represents the detailed description on a page.
authorsection Represents the author section of a page (only used for man pages). This is a separate sec-
tion for man pages with a text like: Generated automatically by Doxygen for My Project
from the source code. This should not be misinterpreted with the doxygen commands \author or
\authors that generate an author paragraph inside a detailed description.
The following generic elements are possible for each page except the concept page:
memberdecl Represents the quick overview of members on a page (member declarations). This elements has
child elements per type of member list. The possible child elements are not listed in detail in the document,
but the name of the element should be a good indication of the type of members that the element represents.
memberdef Represents the detailed member list on a page (member definition). Like the memberdecl ele-
ment, also this element has a number of possible child elements.
The class page has the following specific elements:

15.3 Using the XML output 81
includes Represents the include file needed to obtain the definition for this class.
inheritancegraph Represents the inheritance relations for a class. Note that the CLASS_GRAPH option
determines if the inheritance relation is a list of base and derived classes or a graph.
collaborationgraph Represents the collaboration graph for a class.

allmemberslink Represents the link to the list of all members for a class.
usedfiles Represents the list of files from which documentation for the class was extracted.
The concept page has the following specific elements:
includes Represents the include file needed to obtain the definition for this class.
definition Represents the definition of the concept
The file page has the following specific elements:
includes Represents the list of #include statements contained in this file.

includegraph Represents the include dependency graph for the file.
includedbygraph Represents the included by dependency graph for the file.
sourcelink Represents the link to the source code of this file.
The group page has a specific groupgraph element which represents the graph showing the dependencies
between groups.
Similarly, the directory page has a specific directorygraph element which represents the graph showing the
dependencies between the directories based on the #include relations of the files inside the directories.
Some elements have a visible attribute which can be used to hide the fragment from the generated output, by
setting the attribute's value to ¨no¨. You can also use the value of a configuration option to determine the visibility,
by using its name prefixed with a dollar sign, e.g.
...
<includes visible="$SHOW_INCLUDE_FILES"/>
...
This was mainly added for backward compatibility. Note that the visible attribute is just a hint for doxygen. If no
relevant information is available for a certain piece it is omitted even if it is set to yes (i.e. no empty sections are
generated).
Not all elements have a visible attribute shown in the layout file, though this attribute can be used anyway (the
default is visible=ÿes¨).
Some elements have a title attribute. This attribute can be used to customize the title doxygen will use as a
header for the piece.
15.3 Using the XML output
If the above two methods still do not provide enough flexibility, you can also use the XML output produced by
doxygen as a basis to generate the output you like. To do this set GENERATE_XML to YES.
The XML output consists of an index file named index.xml which lists all items extracted by doxygen with
references to the other XML files for details. The structure of the index is described by a schema file index.xsd.
All other XML files are described by the schema file named compound.xsd. If you prefer one big XML file you
can combine the index and the other files using the XSLT file combine.xslt.
You can use any XML parser to parse the files or use the one that can be found in the addon/doxmlparser
directory of doxygen's source distribution. Look at addon/doxmlparser/doxmlparser/index.py

and addon/doxmlparser/doxmlparser/compound.py for the interface of the parser (it is gener-

ated by generatedDS and follows the XML schema files index.xsd and compound.xsd found in
templates/xml). Look in addon/doxmlparser/examples for examples.
The advantage of using the doxmlparser is that it allows you to only read the index file into memory and then only
those XML files that you implicitly load via navigating through the index. As a result this works even for very large
projects where reading all XML files as one big DOM tree would not fit into memory.
See the Breathe project for an example that uses doxygen XML output from Python to bridge it with the
Sphinx document generator.

Chapter 16
Custom Commands
16.1 Simple aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

16.2 Aliases with arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
16.3 Nesting custom command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Doxygen provides a large number of special commands, XML commands, and HTML commands. that can be used
to enhance or structure the documentation inside a comment block. If you for some reason have a need to define
new commands you can do so by means of an alias definition.
The definition of an alias should be specified in the configuration file using the ALIASES configuration tag.
16.1 Simple aliases
The simplest form of an alias is a simple substitution of the form
name=value
For example defining the following alias:
ALIASES += sideeffect="\par Side Effects:^^"
will allow you to put the command \sideeffect (or @sideeffect) in the documentation, which will result in
a user-defined paragraph with heading Side Effects:.
Note that you cannot put \n's in the value part of an alias to insert newlines (in the resulting output). You can put
∧∧ in the value part of an alias to insert a newline as if a physical newline was in the original file.
Note when you need a literal { or } or , in the value part of an alias you have to escape them by means of a
backslash (\), this can lead to conflicts with the commands \{ and \} for these it is advised to use the version @{
and @} or use a double escape (\\{ and \\})
Also note that you can redefine existing special commands if you wish.
Some commands, such as \xrefitem are designed to be used in combination with aliases.
16.2 Aliases with arguments
Aliases can also have one or more arguments. In the alias definition you then need to specify the number of
arguments between curly braces. In the value part of the definition you can place \x markers, where 'x' represents
the argument number starting with 1.
Here is an example of an alias definition with a single argument:

84 Custom Commands
ALIASES += l{1}="\ref \1"
Inside a comment block you can use it as follows
/** See \l{SomeClass} for more information. */
which would be the same as writing
/** See \ref SomeClass for more information. */
Note that you can overload an alias by a version with multiple arguments, for instance:
ALIASES += l{1}="\ref \1"

ALIASES += l{2}="\ref \1 \"\2\""
Note that the quotes inside the alias definition have to be escaped with a backslash.
With these alias definitions, we can write
/** See \l{SomeClass,Some Text} for more information. */
inside the comment block and it will expand to
/** See \ref SomeClass "Some Text" for more information. */
where the command with a single argument would still work as shown before.
Aliases can also be expressed in terms of other aliases, e.g. a new command \reminder can be expressed as a
\xrefitem via an intermediate \xreflist command as follows:
ALIASES += xreflist{3}="\xrefitem \1 \"\2\" \"\3\" "

ALIASES += reminder="\xreflist{reminders,Reminder,Reminders}"
Note that if for aliases with more than one argument a comma is used as a separator, if you want to put a comma
inside the command, you will need to escape it with a backslash, i.e.
\l{SomeClass,Some text\, with an escaped comma}
given the alias definition of \l in the example above.
16.3 Nesting custom command
You can use commands as arguments of aliases, including commands defined using aliases.
As an example consider the following alias definitions
ALIASES += Bold{1}="<b>\1</b>"
ALIASES += Emph{1}="<em>\1</em>"
Inside a comment block you can now use:
/** This is a \Bold{bold \Emph{and} Emphasized} text fragment. */
which will expand to
/** This is a <b>bold <em>and</em> Emphasized</b> text fragment. */

Chapter 17
Linking to external documentation
If your project depends on external libraries or tools, there are several reasons to not include all sources for these
with every run of doxygen:
Disk space: Some documentation may be available outside of the output directory of doxygen already, for instance
somewhere on the web. You may want to link to these pages instead of generating the documentation in your
local output directory.
Compilation speed: External projects typically have a different update frequency from your own project. It does
not make much sense to let doxygen parse the sources for these external project over and over again, even
if nothing has changed.
Memory: For very large source trees, letting doxygen parse all sources may simply take too much of your system's
memory. By dividing the sources into several ¨packages¨, the sources of one package can be parsed by
doxygen, while all other packages that this package depends on, are linked in externally. This saves a lot of
memory.
Availability: For some projects that are documented with doxygen, the sources may just not be available.
Copyright issues: If the external package and its documentation are copyright someone else, it may be better - or
even necessary - to reference it rather than include a copy of it with your project's documentation. When the
author forbids redistribution, this is necessary. If the author requires compliance with some license condition
as a precondition of redistribution, and you do not want to be bound by those conditions, referring to their
copy of their documentation is preferable to including a copy.
If any of the above apply, you can use doxygen's tag file mechanism. A tag file is basically a compact representation
of the entities found in the external sources. Doxygen can both generate and read tag files.
To generate a tag file for your project, simply put the name of the tag file after the GENERATE_TAGFILE option in
the configuration file.
To combine the output of one or more external projects with your own project you should specify the name of the
tag files after the TAGFILES option in the configuration file.
A tag file typically only contains a relative location of the documentation from the point where doxygen was run.
So when you include a tag file in other project you have to specify where the external documentation is located
in relation this project. You can do this in the configuration file by assigning the (relative) location to the tag files
specified after the TAGFILES configuration option. If you use a relative path it should be relative with respect to the
directory where the HTML output of your project is generated; so a relative path from the HTML output directory of
a project to the HTML output of the other project that is linked to.
Example:
Suppose you have a project proj that uses two external projects called ext1 and ext2. The directory
structure looks as follows:

86 Linking to external documentation
<root>
+- proj
| +- html HTML output directory for proj
| +- src sources for proj
| |- proj.cpp
+- ext1
| +- html HTML output directory for ext1
| |- ext1.tag tag file for ext1
+- ext2
| +- html HTML output directory for ext2
| |- ext2.tag tag file for ext2
|- proj.cfg doxygen configuration file for proj
|- ext1.cfg doxygen configuration file for ext1
|- ext2.cfg doxygen configuration file for ext2
Then the relevant parts of the configuration files look as follows:
proj.cfg:
OUTPUT_DIRECTORY = proj
INPUT = proj/src
TAGFILES = ext1/ext1.tag=../../ext1/html \
ext2/ext2.tag=../../ext2/html
ext1.cfg:
OUTPUT_DIRECTORY = ext1
GENERATE_TAGFILE = ext1/ext1.tag
ext2.cfg:
OUTPUT_DIRECTORY = ext2
GENERATE_TAGFILE = ext2/ext2.tag

Chapter 18
Frequently Asked Questions
18.1 How to get information on the index page in HTML? . . . . . . . . . . . . . . . . . . . . . . . . . . 87

18.2 Help, some/all of the members of my class / file / namespace are not documented? . . . . . . . . . . 88
18.3 When I set EXTRACT_ALL to NO none of my functions are shown in the documentation. . . . . . . . 88
18.4 My file with a custom extension is not parsed (properly) (anymore). . . . . . . . . . . . . . . . . . . 88
18.5 How can I make doxygen ignore some code fragment? . . . . . . . . . . . . . . . . . . . . . . . . . 89
18.6 How can I change what is after the #include in the class documentation? . . . . . . . . . . . . . . . 89
18.7 How can I use tag files in combination with compressed HTML? . . . . . . . . . . . . . . . . . . . . 89
18.8 I don't like the quick index that is put above each HTML page, what do I do? . . . . . . . . . . . . . . 90
18.9 The overall HTML output looks different, while I only wanted to use my own html header file . . . . . 90
18.10 Why does doxygen use Qt? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
18.11 How can I exclude all test directories from my directory tree? . . . . . . . . . . . . . . . . . . . . . . 90
18.12 Doxygen automatically generates a link to the class MyClass somewhere in the running text. How do I
prevent that at a certain place? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
18.13 My favorite programming language is X. Can I still use doxygen? . . . . . . . . . . . . . . . . . . . . 91
18.14 Help! I get the cryptic message ïnput buffer overflow, can't enlarge buffer because scanner uses
REJECT¨ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
18.15 When running make in the latex directory I get ¨TeX capacity exceeded¨. Now what? . . . . . . . . . 91
18.16 Why are dependencies via STL classes not shown in the dot graphs? . . . . . . . . . . . . . . . . . 91
18.17 I have problems getting the search engine to work with PHP5 and/or windows . . . . . . . . . . . . . 91
18.18 Can I configure doxygen from the command line? . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
18.19 How did doxygen get its name? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
18.20 What was the reason to develop doxygen? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
18.21 How to prevent interleaved output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
18.1 How to get information on the index page in HTML?
You should use the \mainpage command inside a comment block like this:
/*! \mainpage My Personal Index Page

*
* \section intro_sec Introduction
*

88 Frequently Asked Questions
* This is the introduction.

*
* \section install_sec Installation
*
* \subsection step1 Step 1: Opening the box
*
* etc...
*/
18.2 Help, some/all of the members of my class / file / namespace are not
documented?
Check the following:
1. Is your class / file / namespace documented? If not, it will not be extracted from the sources unless
EXTRACT_ALL is set to YES in the configuration file.
2. Are the members private? If so, you must set EXTRACT_PRIVATE to YES to make them appear in the
documentation.
3. Is there a function macro in your class that does not end with a semicolon (e.g. MY_MACRO())? If so then
you have to instruct doxygen's preprocessor to remove it.
This typically boils down to the following settings in the configuration file:
PREDEFINED = MY_MACRO()=
Please read the preprocessing section of the manual for more information.
18.3 When I set EXTRACT_ALL to NO none of my functions are shown in

the documentation.
In order for global functions, variables, enums, typedefs, and defines to be documented you should document the
file in which these commands are located using a comment block containing a \file (or @file) command.
Alternatively, you can put all members in a group (or module) using the \ingroup command and then document the
group using a comment block containing the \defgroup command.
For member functions or functions that are part of a namespace you should document either the class or names-
pace.
18.4 My file with a custom extension is not parsed (properly) (anymore).
Doxygen only parses files that are specified as input (via the INPUT tag) and that match a specified extension
(mentioned in FILE_PATTERNS) The list of files is then reduced by excluding files listed as EXCLUDE or files that
match the patterns set by EXCLUDE_PATTERNS.
In the past doxygen parsed all files with an unknown extension as C files which could lead to undesired results.
Since version 1.8.8, doxygen requires that you specify a mapping that tells for a certain file extension, which parser
to use. This mapping is specified using the EXTENSION_MAPPING tag. If no mapping is specified the file's
contents will be ignored.

18.5 How can I make doxygen ignore some code fragment? 89
18.5 How can I make doxygen ignore some code fragment?
The new and easiest way is to add one comment block with a \cond command at the start and one comment block
with a \endcond command at the end of the piece of code that should be ignored. This should be within the same
file of course.
But you can also use doxygen's preprocessor for this: If you put
#ifndef DOXYGEN_SHOULD_SKIP_THIS
/* code that must be skipped by doxygen */
#endif /* DOXYGEN_SHOULD_SKIP_THIS */
around the blocks that should be hidden and put:
PREDEFINED = DOXYGEN_SHOULD_SKIP_THIS
in the configuration file then all blocks should be skipped by doxygen as long as ENABLE_PREPROCESSING is
set to YES.
18.6 How can I change what is after the #include in the class
documentation?
In most cases you can use STRIP_FROM_INC_PATH to strip a user defined part of a path.
You can also document your class as follows
/*! \class MyClassName include.h path/include.h

*
* Docs for MyClassName
*/
To make doxygen put
#include <path/include.h>
in the documentation of the class MyClassName regardless of the name of the actual header file in which the
definition of MyClassName is contained.
If you want doxygen to show that the include file should be included using quotes instead of angle brackets you
should type:
/*! \class MyClassName myhdr.h "path/myhdr.h"

*
* Docs for MyClassName
*/
18.7 How can I use tag files in combination with compressed HTML?
If you want to refer from one compressed HTML file a.chm to another compressed HTML file called b.chm, the
link in a.chm must have the following format:
<a href="mk:@MSITStore:b.chm::/file.html">
Unfortunately this only works if both compressed HTML files are in the same directory.

As a result you must rename the generated index.chm files for all projects into something unique and put all
.chm files in one directory.
Suppose you have a project a referring to a project b using tag file b.tag, then you could rename the index.chm
for project a into a.chm and the index.chm for project b into b.chm. In the configuration file for project a you
write:
TAGFILES = b.tag=mk:@MSITStore:b.chm::
18.8 I don't like the quick index that is put above each HTML page, what
do I do?
You can disable the index by setting DISABLE_INDEX to YES. Then you can put in your own header file by writing
your own header and feed that to HTML_HEADER.
18.9 The overall HTML output looks different, while I only wanted to use
my own html header file
You probably forgot to include the stylesheet doxygen.css that doxygen generates. You can include this by
putting
<LINK HREF="doxygen.css" REL="stylesheet" TYPE="text/css">
in the HEAD section of the HTML page.
18.10 Why does doxygen use Qt?
In the past (prior to version 1.9.2) doxygen used a part of Qt 2.x for various utility classes. These have been replaced
by STL container classes in the meantime.
The GUI front-end called Doxywizard is based on a modern version of Qt. Doxygen itself can also be used without
the GUI.
18.11 How can I exclude all test directories from my directory tree?
Simply put an exclude pattern like this in the configuration file:
EXCLUDE_PATTERNS = */test/*
18.12 Doxygen automatically generates a link to the class MyClass

somewhere in the running text. How do I prevent that at a certain
place?
Put a % in front of the class name. Like this: %MyClass. Doxygen will then remove the % and keep the word
unlinked.

18.13 My favorite programming language is X. Can I still use doxygen? 91
18.13 My favorite programming language is X. Can I still use doxygen?
No, not as such; doxygen needs to understand the structure of what it reads. If you don't mind spending some time
on it, there are several options:
• If the grammar of X is close to C or C++, then it is probably not too hard to tweak src/scanner.l a bit so
the language is supported. This is done for all other languages directly supported by doxygen (i.e. Java, IDL,
C#, PHP).
• If the grammar of X is somewhat different than you can write an input filter that translates X into something
similar enough to C/C++ for doxygen to understand (this approach is taken for VB, Object Pascal, and Java←-
Script, see https://www.doxygen.org/download.html#helpers).
• If the grammar is completely different one could write a parser for X and write a backend that produces a
similar syntax tree as is done by src/scanner.l (and also by src/tagreader.cpp while reading
tag files).
18.14 Help! I get the cryptic message ïnput buffer overflow, can't
enlarge buffer because scanner uses REJECT¨
This error happens when doxygen's lexical scanner has a rule that matches more than 256K of input characters
in one go. I've seen this happening on a very large generated file (>256K lines), where the built-in preprocessor
converted it into an empty file (with >256K of newlines). Another case where this might happen is if you have lines
in your code with more than 256K characters.
If you have run into such a case and want me to fix it, you should send me a code fragment that triggers the
message. To work around the problem, put some line-breaks into your file, split it up into smaller parts, or exclude
it from the input using EXCLUDE.
Another way to work around this problem is to use the cmake command with the option:
-Denlarge_lex_buffers=<size>
where <size> is the new size of the input (YY_BUF_SIZE) and read (YY_READ_BUF_SIZE) buffer. In case
this option is not given the default value of 262144 (i.e. 256K) will be used.
18.15 When running make in the latex directory I get ¨TeX capacity
exceeded¨. Now what?
You can edit the texmf.cfg file to increase the default values of the various buffers and then run ¨texconfig init¨.
18.16 Why are dependencies via STL classes not shown in the dot
graphs?
Doxygen is unaware of the STL classes, unless the option BUILTIN_STL_SUPPORT is turned on.
18.17 I have problems getting the search engine to work with PHP5
and/or windows
Please read this for hints on where to look.

18.18 Can I configure doxygen from the command line?
Not via command line options, but doxygen can read from stdin, so you can pipe things through it. Here's an ex-
ample how to override an option in a configuration file from the command line (assuming a UNIX like environment):
( cat Doxyfile ; echo "PROJECT_NUMBER=1.0" ) | doxygen -
For Windows command line the following would do the same:
( type Doxyfile & echo PROJECT_NUMBER=1.0 ) | doxygen.exe -
For Windows Powershell (checked with version 5.1) the following would do the same:
&{ type Doxyfile ; echo "PROJECT_NUMBER=1.0" } | doxygen -
If multiple options with the same name are specified then doxygen will use the last one. To append to an existing
option you can use the += operator.
18.19 How did doxygen get its name?
Doxygen got its name from playing with the words documentation and generator.
documentation -> docs -> dox

generator -> gen
At the time I was looking into lex and yacc, where a lot of things start with ÿy¨, so the ÿ¨ slipped in and made
things pronounceable (the proper pronouncement is Docs-ee-gen, so with a long ë¨).
18.20 What was the reason to develop doxygen?
I once wrote a GUI widget based on the Qt library (it is still available at https://sourceforge.←-
net/projects/qdbttabular/ but hasn't been updated since 2002). Qt had nicely generated documentation
(using an internal tool which they didn't want to release) and I wrote similar docs by hand. This was
a nightmare to maintain, so I wanted a similar tool. I looked at Doc++ but that just wasn't good enough (it didn't
support signals and slots and did not have the Qt look and feel I had grown to like), so I started to write my own
tool...
18.21 How to prevent interleaved output
When redirecting all the console output of doxygen, i.e. messages and warnings, this can be interleaved or in a
non-expected order. The, technical, reason for this is that the stdout can be buffered. It is possible to overcome
this by means of the -b of doxygen, like e.g doxygen -b > out.txt 2>&1. Note this might cost a little
more time though.

Chapter 19
Troubleshooting
19.1 Known Problems
• Doxygen is not a real compiler, it is only a lexical scanner. This means that it can and will not detect errors in
your source code.
• Doxygen has a built-in preprocessor, but this works slightly different than the C preprocessor. Doxygen
assumes a header file is properly guarded against multiple inclusion, and that each include file is standalone
(i.e. it could be placed at the top of a source file without causing compiler errors). As long as this is true (and
this is a good design practice) you should not encounter problems.
• Since it is impossible to test all possible code fragments, it is very well possible, that some valid piece of C/←-
C++ code is not handled properly. If you find such a piece, please send it to me, so I can improve doxygen's
parsing capabilities. Try to make the piece of code you send as small as possible, to help me narrow down
the search.
• Doxygen does not work properly if there are multiple classes, structs or unions with the same name in your
code. It should not crash however, rather it should ignore all of the classes with the same name except one.
• Some commands do not work inside the arguments of other commands. Inside a HTML link (i.←-
e. <A HREF="...">...</A>) for instance other commands (including other HTML commands) do not work!
The sectioning commands are an important exception.
• Redundant braces can confuse doxygen in some cases. For example:
void f (int);
is properly parsed as a function declaration, but
const int (a);
is also seen as a function declaration with name int, because only the syntax is analyzed, not the semantics.
If the redundant braces can be detected, as in
int *(a[20]);
then doxygen will remove the braces and correctly parse the result.
• Not all names in code fragments that are included in the documentation are replaced by links (for instance
when using SOURCE_BROWSER = YES) and links to overloaded members may point to the wrong member.
This also holds for the ¨Referenced by¨ list that is generated for each function.
For a part this is because the code parser isn't smart enough at the moment. I'll try to improve this in the future.
But even with these improvements not everything can be properly linked to the corresponding documentation,
because of possible ambiguities or lack of information about the context in which the code fragment is found.
• It is not possible to insert a non-member function f in a class A using the \relates or \relatesalso command, if
class A already has a member with name f and the same argument list.

94 Troubleshooting
• There is only very limited support for member specialization at the moment. It only works if there is a special-
ized template class as well.
• Not all special commands are properly translated to RTF.
• Version 1.8.6 of dot (and maybe earlier versions too) do not generate proper map files, causing the graphs
that doxygen generates not to be properly clickable.
• PHP only: Doxygen requires that all PHP statements (i.e. code) is wrapped in a functions/methods, otherwise
you may run into parse problems.
19.2 How to Help
The development of doxygen highly depends on your input!

If you are trying doxygen let me know what you think of it (do you miss certain features?). Even if you decide not to
use it, please let me know why.
19.3 How to report a bug
Bugs are tracked in GitHub's issue tracker. Before submitting a new bug, first search through the
database if the same bug has already been submitted by others. If you believe you have found a new bug, please
report it.
If you are unsure whether or not something is a bug, please ask help first (subscription is required) on the users
mailing list or at Stack Overflow using the doxygen label.
If you send only a (vague) description of a bug, you are usually not very helpful and it will cost me much more time
to figure out what you mean. In the worst-case your bug report may even be completely ignored by me, so always
try to include the following information in your bug report:
• The version of doxygen you are using (for instance 1.5.3, use doxygen --version if you are not sure or
doxygen --Version for a bit more information).
• The name and version number of your operating system (for instance Ubuntu Linux 18.04 LTS)
• It is usually a good idea to send along the configuration file as well, but please use doxygen with the -s flag
while generating it to keep it small (use doxygen -s -u [configName] to strip the comments from
an existing configuration file. Better even to use the -x or the -x_noenv flag on the used [config←-
Name] to get the differences between the used settings and the doxygen default settings, so doxygen -x
[configName]).
• The easiest (and often the only) way for me to fix bugs is if you can attach a small example demonstrating the
problem you have to the bug report, so I can reproduce it on my machine. Please make sure the example is
valid source code (could potentially compile) and that the problem is really captured by the example (I often
get examples that do not trigger the actual bug!). If you intend to send more than one file please zip or tar the
files together into a single file for easier processing. Note that when reporting a new bug you'll get a chance
to attach a file to it only after submitting the initial bug description.
• Before submitting, consider also running doxygen with some debugging flags, run doxygen -d for all flags.
The option preprocessor might give you hints on how doxygen is understanding your input files.
You can (and are encouraged to) add a patch for a reported bug. If you do so, please use ïssue #NUMBER
TITLE¨ as a title in the pull request form, where ¨NUMBER¨ and ¨TITLE¨ refer to the associated issue on
GitHub.
If you have ideas how to fix existing bugs and limitations please discuss them on the developers mailing
list (subscription required). Patches can also be sent directly to doxygen@gmail.com if you prefer not to
send them via the bug tracker or mailing list.

19.3 How to report a bug 95
For patches please use ¨diff -uN¨ or include the files you modified. If you send more than one file please tar or zip
everything, so I only have to save and download one file.

96 Troubleshooting

Part II
Reference Manual
Chapter 20
Features
• Requires very little overhead from the writer of the documentation. Plain text will do, Markdown is support,
and for more fancy or structured output HTML tags and/or some of doxygen's special commands can be
used.
• Cross platform: works on Windows and many Unix flavors (including Linux and MacOSX).
• Indexes, organizes and generates browsable and cross-referenced output even from undocumented code.
• Generates structured XML output for parsed sources, which can be used by external tools.
• Supports C/C++, Lex, Java, (Corba and Microsoft) Java, Python, VHDL, PHP IDL, C#, Fortran, Objective-C
2.0, and to some extent D sources.
• Supports documentation of files, namespaces, packages, classes, structs, unions, templates, variables, func-
tions, typedefs, enums and defines.
• Javadoc (1.1), qdoc3 (partially), and ECMA-334 (C# spec.) compatible.
• Comes with a GUI frontend (Doxywizard) to ease editing the options and run doxygen. The GUI is available
on Windows, Linux, and MacOSX.
• Automatically generates class and collaboration diagrams in HTML (as clickable image maps) and LATEX (as
Encapsulated PostScript images).
• Uses the dot tool of the Graphviz tool kit to generate include dependency graphs, collaboration diagrams,
call graphs, directory structure graphs, and graphical class hierarchy graphs.
• Allows grouping of entities in modules and creating a hierarchy of modules.
• Flexible comment placement: Allows you to put documentation in the header file (before the declaration of an
entity), source file (before the definition of an entity) or in a separate file.
• Generates a list of all members of a class (including any inherited members) along with their protection level.
• Outputs documentation in on-line format (XHTML and UNIX man page) and off-line format ( LATEX and RTF)
simultaneously (any of these can be disabled if desired). All formats are optimized for ease of reading.
Furthermore, compressed HTML can be generated from HTML output using Microsoft's HTML Help Work-
shop (Windows only) and PDF can be generated from the LATEX output.
• Support for various third party help formats including HTML Help, docsets, Qt-Help, and eclipse help.
• Includes a full C preprocessor to allow proper parsing of conditional code fragments and to allow expansion
of all or part of macros definitions.
• Automatically detects public, protected and private sections, as well as the Qt specific signal and slots sec-
tions. Extraction of private class members is optional.
• Automatically generates references to documented classes, files, namespaces and members. Documentation
of global functions, global variables, typedefs, defines and enumerations is also supported.

100 Features
• References to base/super classes and inherited/overridden members are generated automatically.
• Includes a fast, rank based search engine to search for strings or words in the class and member documen-
tation (PHP based).
• Includes an JavaScript based live search feature to search for symbols as you type (for small to medium sized
projects).
• You can type normal HTML tags in your documentation. Doxygen will convert them to their equivalent LATEX,
RTF, and man-page counterparts automatically.
• Allows references to documentation generated for other (doxygen documented) projects (or another part of
the same project) in a location independent way.
• Allows inclusion of source code examples that are automatically cross-referenced with the documentation.
• Inclusion of undocumented classes is also supported, allowing to quickly learn the structure and interfaces of
a (large) piece of code without looking into the implementation details.
• Allows automatic cross-referencing of (documented) entities with their definition in the source code.
• All source code fragments are syntax highlighted for ease of reading.
• Allows inclusion of function/member/class definitions in the documentation.
• All options are read from an easy to edit and (optionally) annotated configuration file.
• Documentation and search engine can be transferred to another location or machine without regenerating the
documentation.
• Supports many different character encodings and uses UTF-8 internally and for the generated output.
• Doxygen can generate a layout which you can use and edit to change the layout of each page.
• There more than a 100 configurable options to fine-tune the output.
• Can cope with large projects easily.
Although doxygen can now be used in any project written in a language that is supported by doxygen, initially it was
specifically designed to be used for projects that make use of Qt Software's Qt toolkit. I have tried to make
doxygen ‘Qt-compatible’. That is: Doxygen can read the documentation contained in the Qt source code and create
a class browser that looks quite similar to the one that is generated by Qt Software. Doxygen understands the C++
extensions used by Qt such as signals and slots and many of the markup commands used in the Qt sources.
Doxygen can also automatically generate links to existing documentation that was generated with doxygen or with
Qt's non-public class browser generator. For a Qt based project this means that whenever you refer to members or
classes belonging to the Qt toolkit, a link will be generated to the Qt documentation. This is done independent of
where this documentation is located!

Chapter 21
Doxygen usage
Doxygen is a command line based utility. Calling doxygen with the --help option at the command line will give
you a brief description of the usage of the program.
All options consist of a leading character -, followed by one character and one or more arguments depending on
the option.
To generate a manual for your project you typically need to follow these steps:
1. You document your source code with special documentation blocks (see section Special comment blocks).
2. You generate a configuration file (see section Configuration) by calling doxygen with the -g option:
doxygen -g <config_file>
3. You edit the configuration file so it matches your project. In the configuration file you can specify the input
files and a lot of optional information.
4. You let doxygen generate the documentation, based on the settings in the configuration file:
doxygen <config_file>
If you have a configuration file generated with an older version of doxygen, you can upgrade it to the current version
by running doxygen with the -u option.
doxygen -u <config_file>
All configuration settings in the original configuration file will be copied to the new configuration file. Any new options
will have their default value. Note that comments that you may have added in the original configuration file will be
lost.
21.1 Fine-tuning the output
If you want to fine-tune the way the output looks, doxygen allows you generate default style sheet, header, and
footer files that you can edit afterwards:
• For HTML output, you can generate the default header file (see HTML_HEADER), the default footer (see
HTML_FOOTER), and the default style sheet (see HTML_STYLESHEET), using the following command:
doxygen -w html header.html footer.html stylesheet.css <config_file>
The config_file is optional. When omitted doxygen will search for a file named Doxyfile and process
that. When this is also not found it will used the default settings.

102 Doxygen usage
• For LATEX output, you can generate the first and last part of refman.tex (see LATEX_HEADER and
LATEX_FOOTER) and the style sheet included by that header (normally doxygen.sty), using the fol-
lowing command:
doxygen -w latex header.tex footer.tex doxygen.sty <config_file>
If you need non-default options (for instance to use extra LATEX packages) you need to make a configuration
file with those options set correctly and then specify that configuration file after the generated files (make a
backup of the configuration file first so you don't loose it in case you forget to specify one of the output files).
• For RTF output, you can generate the default style sheet file (see RTF_STYLESHEET_FILE) using:
doxygen -w rtf rtfstyle.cfg
Warning
When using a custom header you are responsible for the proper inclusion of any scripts and style sheets that
doxygen needs, which is dependent on the configuration options and may change when upgrading to a new
doxygen release.
Note
• If you do not want documentation for each item inside the configuration file then you can use the optional
-s option. This can use be used in combination with the -u option, to add or strip the documentation
from an existing configuration file. To get a minimal configuration file use the -x or -x_noenv option
to show only the differences from the default doxygen configuration file. Please use the -s or -x or
-x_noenv option if you send me a configuration file as part of a bug report or post an issue on GitHub!
(see also: How to report a bug)
• To make doxygen read/write to standard input/output instead of from/to a file, use - for the file name.

Chapter 22
Doxywizard usage
Doxywizard is a GUI front-end for configuring and running doxygen.

When starting doxywizard one can specify an existing configuration file to use as argument, otherwise the default
settings will be used as a starting point.
When you start doxywizard it will display the main window (the actual look depends on the platform used).
Figure 22.1: Main window
The user interface consists of the following sections:

104 Doxywizard usage
Menu options In the menu bar the following parts are available: File menu, Settings menu and Help menu.
Specify the working directory from which doxygen will run Using the Select... button a directory can be
selected. When doxywizard is started with a configuration file or one is loaded using the open command
(see: File menu) the directory of this settings file used as the working directory.
Configure doxygen using the Wizard and/or Expert tab...
Wizard tab with this tab it is possible to quickly configure the most important settings and leave the rest of
the options to their defaults.
Expert tab with this tab one gains access to the full set of configuration options.
Run tab with this tab it is possible to run doxygen and view the used settings.
Switching between these tabs is possible, e.g you could start with the wizard tab and then fine tune some
settings by switching to the expert tab.
After doxygen is configured you need to save (see: File menu) the configuration as a file to disk. This allows
doxygen to use the configuration and also allows running doxygen again with the same settings at a later point in
time.
Since some configuration options may use relative paths, be sure to select a working directory that is root of those
paths. This is often the root of the source tree and will typically be correctly filled in if the configuration file is stored
at this location as well.
Once the configuration file is saved and the working directory is set, you can run doxygen based on the selected
settings. Do this by switching to the Run tab, and click the ¨Run doxygen¨ button.
Once doxygen runs you can cancel it by clicking the same button again. The output produced by doxygen is
captured and shown in the Öutput produced by doxygen¨ pane. Once doxygen finishes, the log can be saved as a
text file.
22.1 Wizard tab
The Wizard tab is divided into two panes
Left pane The main topics for easy setting up doxygen. By clicking on a topic the corresponding settings will
appear in the Right pane.
Right pane The wizard's settings pane, in this pane you will find the settings that are available for the selected
topic.
The wizard only gives the possibility to quickly setup doxygen, for full control one should use the Expert tab.

22.1 Wizard tab 105
22.1.1 Project settings
The fields in the Project pane speak for themselves. Once doxygen has finished the Destination directory is where
to look for the results. Doxygen will put each output format in a separate sub-directory by default.
Figure 22.2: Wizard tab: Project settings

22.1.2 Mode of operating
The Mode pane allows you to select how doxygen will look at your sources. The default is to only look for things
that have been documented. Furthermore, the terminology used in the output can be changed to better match the
main programming language used (this doesn't affect the way doxygen parses your source code).
Figure 22.3: Wizard tab: Mode of operating

22.1 Wizard tab 107
22.1.3 Output to produce
The Output pane allows you to select what kinds of output doxygen will produce. For HTML and LATEX there are
additional options available.
Figure 22.4: Wizard tab: Output to produce

22.1.4 Diagrams to generate
Doxygen can produce a number of diagrams. Using the Diagrams pane you can select which ones to generate. For
most diagrams the dot tool of the GraphViz package is needed. This needs to be installed separately.
Figure 22.5: Wizard tab: Diagrams to generate
22.2 Expert tab
The Expert tab is divided into a number of panes:
Top left pane The Topics pane (i.e. sections in the configuration file) that are available. By clicking on a topic the
corresponding settings will appear in the Right pane.
Bottom left pane The help pane, this will be updated when one hovers over the name of a setting in the Right
pane.
Right pane The Settings pane, in this pane you will find the settings that are available for the selected topic. In
case the name for a setting is colored red, the setting has a non-default value. In case a setting is grayed out,
the setting is depending on another setting that is disabled. Which setting it depends on is indicated in the
help pane on the bottom left.

22.2 Expert tab 109
Figure 22.6: Some options from the Expert tab
The representation of the input field depends on the type of the configuration option.
• For each boolean option (those options that are answered with YES or NO in the configuration file) there is a
check-box. A typical field looks like:
• For items taking one of a fixed set of values (like OUTPUT_LANGUAGE) a combo box is used. A typical field
looks like:
• For items taking an integer value from a range, a spinbox is used. A typical field looks like:
• For free form string-type options there is a one line edit field. A typical field looks like:
Additionally, when the string field should contain a file or a folder name, there are the special buttons and

that start a file / folder selection dialog. A typical field for a file looks like:
and a folder looks like:
and in case both a file or a folder is allowed, the look is:
In case a file represents an image, doxygen also tries to display the selected image. Then a typical field looks
like:
• For options taking a list of strings, an editor field is shown with a non-editable list below it. The button
adds the string in the editor field to the list and a the button removes the selected string from the list. The
button can be clicked to replace the selected item in the list with the string entered in the editor field. A
typical field looks like:
additionally when the list contains file and / or folder names, there are special buttons and that start
a file / folder selection dialog. A typical field would for a file looks like:
and for a folder it looks like
and in case both files and folders are allowed, the look is:

22.3 Run tab 111
22.3 Run tab
The run tab gives the possibility to run doxygen with the given settings, see the HTML results, see the settings used
and save the output as displayed in the output pane.
Figure 22.7: Run tab
Specify additional command line options for running doxygen Field to specify extra options used when run-
ning doxygen, e.g. for debugging purposes.
Run doxygen When clicked will start running doxygen. The Öutput produced by doxygen¨ pane shows the mes-
sages produced by doxygen while it is running. Before being able to run doxygen the settings have to be
saved.
Show HTML output Clicking this button will open the main HTML output page in the default browser. The button
will be enabled after doxygen has finished.

Show configuration Clicking this button shows the configuration settings that are used when running doxygen.
The results will be shown in the Öutput produced by doxygen¨ pane in compact textual form.
Condensed When checked the ¨Show configuration¨ button will only list the configuration settings that differ from
the default settings (analogous to doxygen -x).
Save Log ... Will save the information from the Öutput produced by doxygen¨ pane in a file as specified by the
user.
22.4 Menu options
22.4.1 File menu
The file menu with a couple of useful items for loading and saving settings.
Figure 22.8: File menu
Open... Load a configuration file from disk, based on a file selection dialog. In case unsaved settings exist you will
be asked to confirm the action.
Open recent Quickly load a recently saved configuration file. In case unsaved settings exist you will be asked to
confirm the action. This menu item is only accessible when there are recent files in the list.
Save Saves a configuration file to disk. In case the configuration file has already been set this file name is used
otherwise a selection dialog will appear. In case the file already exists a confirmation is required.
Save as.. Saves the current configuration settings to disk with a specific name. This file name will become the
currently set file name.
Quit Leave doxywizard, in case unsaved settings exist you will be asked to confirm the action.
22.4.2 Settings menu
Figure 22.9: Settings menu
Reset to factory defaults Restores the factory defaults as the default settings to use. You will be asked to confirm
the action. This menu item is only accessible when the current settings differ from the default settings.
Use current settings at startup Stores the current configuration settings as the default to use next time the GUI
is started. You will be asked to confirm the action.

22.4 Menu options 113
Clear recent list Clears the Öpen recent¨ list in the File menu. This menu item is only accessible when there are
recent files in the Öpen recent¨ list.
22.4.3 Help menu
Figure 22.10: Help menu
Online Manual Opens the doxygen manual from the doxygen home page in the system defined default HTML
browser.
About Shows an About dialog with version information.


Chapter 23
Configuration
23.1 Format
A configuration file is a free-form ASCII text file with a structure that is similar to that of a Makefile, with the default
name Doxyfile. It is parsed by doxygen. The file may contain tabs and newlines for formatting purposes. The
statements in the file are case-sensitive. Comments may be placed anywhere within the file (except within quotes).
Comments beginning with two hash characters (##) are kept when updating the configuration file and are placed
in front of the TAG they are in front of. Comments beginning with two hash characters (##) at the beginning of
the configuration file are also kept and placed at the beginning of the file. Comments beginning with two hash
characters (##) at the end of the configuration file are also kept and placed at the end of the file. Comments begin
with the hash character (#) and ends at the end of the line.
The file essentially consists of a list of assignment statements. Each statement consists of a TAG_NAME written in
capitals, followed by the equal sign (=) and one or more values. If the same tag is assigned more than once, the last
assignment overwrites any earlier assignment. For tags that take a list as their argument, the += operator can be
used instead of = to append new values to the list. Values are sequences of non-blanks. If the value should contain
one or more blanks it must be surrounded by quotes ("..."). Multiple lines can be concatenated by inserting a
backslash (\) as the last character of a line.
Environment variables can be expanded using the pattern $(ENV_VARIABLE_NAME). A small example:
DOT_PATH = $(YOUR_DOT_PATH)
You can also include part of a configuration file from another configuration file using a @INCLUDE tag as follows:
@INCLUDE = config_file_name
The include file is searched in the current working directory. You can also specify a list of directories that should
be searched before looking in the current working directory. Do this by putting a @INCLUDE_PATH tag with these
paths before the @INCLUDE tag, e.g.:
@INCLUDE_PATH = my_config_dir
The configuration options can be divided into several categories. Below is an alphabetical index of the tags that are
recognized followed by the descriptions of the tags grouped by category.
ABBREVIATE_BRIEF . . . . . . . . . . . . . . . . . . . . 23.2 BRIEF_MEMBER_DESC . . . . . . . . . . . . . . . . . . 23.2

ALIASES . . . . . . . . . . . . . . . . . . . . . . . . . . 23.2 BUILTIN_STL_SUPPORT . . . . . . . . . . . . . . . . . . 23.2
ALLEXTERNALS . . . . . . . . . . . . . . . . . . . . . .23.18 CALLER_GRAPH . . . . . . . . . . . . . . . . . . . . . .23.19
ALLOW_UNICODE_NAMES . . . . . . . . . . . . . . . . 23.2 CALL_GRAPH . . . . . . . . . . . . . . . . . . . . . . . .23.19
ALPHABETICAL_INDEX . . . . . . . . . . . . . . . . . . 23.7 CASE_SENSE_NAMES . . . . . . . . . . . . . . . . . . . 23.3
ALWAYS_DETAILED_SEC . . . . . . . . . . . . . . . . . 23.2 CHM_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . 23.8
AUTOLINK_SUPPORT . . . . . . . . . . . . . . . . . . . 23.2 CHM_INDEX_ENCODING . . . . . . . . . . . . . . . . . 23.8
BINARY_TOC . . . . . . . . . . . . . . . . . . . . . . . . 23.8 CITE_BIB_FILES . . . . . . . . . . . . . . . . . . . . . . 23.3

116 Configuration
CLANG_ADD_INC_PATHS . . . . . . . . . . . . . . . . . 23.6 FORMULA_MACROFILE . . . . . . . . . . . . . . . . . . 23.8

CLANG_ASSISTED_PARSING . . . . . . . . . . . . . . . 23.6 FORTRAN_COMMENT_AFTER . . . . . . . . . . . . . . 23.5
CLANG_DATABASE_PATH . . . . . . . . . . . . . . . . . 23.6 FULL_PATH_NAMES . . . . . . . . . . . . . . . . . . . . 23.2
CLANG_OPTIONS . . . . . . . . . . . . . . . . . . . . . 23.6 FULL_SIDEBAR . . . . . . . . . . . . . . . . . . . . . . . 23.8
CLASS_GRAPH . . . . . . . . . . . . . . . . . . . . . . .23.19 GENERATE_AUTOGEN_DEF . . . . . . . . . . . . . . .23.14
COLLABORATION_GRAPH . . . . . . . . . . . . . . . . .23.19 GENERATE_BUGLIST . . . . . . . . . . . . . . . . . . . 23.3
COMPACT_LATEX . . . . . . . . . . . . . . . . . . . . . 23.9 GENERATE_CHI . . . . . . . . . . . . . . . . . . . . . . 23.8
COMPACT_RTF . . . . . . . . . . . . . . . . . . . . . . .23.10 GENERATE_DEPRECATEDLIST . . . . . . . . . . . . . . 23.3
CPP_CLI_SUPPORT . . . . . . . . . . . . . . . . . . . . 23.2 GENERATE_DOCBOOK . . . . . . . . . . . . . . . . . .23.13
CREATE_SUBDIRS . . . . . . . . . . . . . . . . . . . . . 23.2 GENERATE_DOCSET . . . . . . . . . . . . . . . . . . . 23.8
CREATE_SUBDIRS_LEVEL . . . . . . . . . . . . . . . . 23.2 GENERATE_ECLIPSEHELP . . . . . . . . . . . . . . . . 23.8
DIAFILE_DIRS . . . . . . . . . . . . . . . . . . . . . . .23.19 GENERATE_HTML . . . . . . . . . . . . . . . . . . . . . 23.8
DIA_PATH . . . . . . . . . . . . . . . . . . . . . . . . . .23.19 GENERATE_HTMLHELP . . . . . . . . . . . . . . . . . . 23.8
DIRECTORY_GRAPH . . . . . . . . . . . . . . . . . . . .23.19 GENERATE_LATEX . . . . . . . . . . . . . . . . . . . . . 23.9
DIR_GRAPH_MAX_DEPTH . . . . . . . . . . . . . . . . .23.19 GENERATE_LEGEND . . . . . . . . . . . . . . . . . . .23.19
DISABLE_INDEX . . . . . . . . . . . . . . . . . . . . . . 23.8 GENERATE_MAN . . . . . . . . . . . . . . . . . . . . . .23.11
DISTRIBUTE_GROUP_DOC . . . . . . . . . . . . . . . . 23.2 GENERATE_PERLMOD . . . . . . . . . . . . . . . . . .23.16
DOCBOOK_OUTPUT . . . . . . . . . . . . . . . . . . . .23.13 GENERATE_QHP . . . . . . . . . . . . . . . . . . . . . . 23.8
DOCSET_BUNDLE_ID . . . . . . . . . . . . . . . . . . . 23.8 GENERATE_RTF . . . . . . . . . . . . . . . . . . . . . .23.10
DOCSET_FEEDNAME . . . . . . . . . . . . . . . . . . . 23.8 GENERATE_SQLITE3 . . . . . . . . . . . . . . . . . . .23.15
DOCSET_FEEDURL . . . . . . . . . . . . . . . . . . . . 23.8 GENERATE_TAGFILE . . . . . . . . . . . . . . . . . . . .23.18
DOCSET_PUBLISHER_ID . . . . . . . . . . . . . . . . . 23.8 GENERATE_TESTLIST . . . . . . . . . . . . . . . . . . . 23.3
DOCSET_PUBLISHER_NAME . . . . . . . . . . . . . . . 23.8 GENERATE_TODOLIST . . . . . . . . . . . . . . . . . . 23.3
DOTFILE_DIRS . . . . . . . . . . . . . . . . . . . . . . .23.19 GENERATE_TREEVIEW . . . . . . . . . . . . . . . . . . 23.8
DOT_CLEANUP . . . . . . . . . . . . . . . . . . . . . . .23.19 GENERATE_XML . . . . . . . . . . . . . . . . . . . . . .23.12
DOT_COMMON_ATTR . . . . . . . . . . . . . . . . . . .23.19 GRAPHICAL_HIERARCHY . . . . . . . . . . . . . . . . .23.19
DOT_EDGE_ATTR . . . . . . . . . . . . . . . . . . . . .23.19 GROUP_GRAPHS . . . . . . . . . . . . . . . . . . . . .23.19
DOT_FONTPATH . . . . . . . . . . . . . . . . . . . . . .23.19 GROUP_NESTED_COMPOUNDS . . . . . . . . . . . . . 23.2
DOT_GRAPH_MAX_NODES . . . . . . . . . . . . . . . .23.19 HAVE_DOT . . . . . . . . . . . . . . . . . . . . . . . . .23.19
DOT_IMAGE_FORMAT . . . . . . . . . . . . . . . . . . .23.19 HHC_LOCATION . . . . . . . . . . . . . . . . . . . . . . 23.8
DOT_MULTI_TARGETS . . . . . . . . . . . . . . . . . . .23.19 HIDE_COMPOUND_REFERENCE . . . . . . . . . . . . . 23.3
DOT_NODE_ATTR . . . . . . . . . . . . . . . . . . . . .23.19 HIDE_FRIEND_COMPOUNDS . . . . . . . . . . . . . . . 23.3
DOT_NUM_THREADS . . . . . . . . . . . . . . . . . . .23.19 HIDE_IN_BODY_DOCS . . . . . . . . . . . . . . . . . . . 23.3
DOT_PATH . . . . . . . . . . . . . . . . . . . . . . . . .23.19 HIDE_SCOPE_NAMES . . . . . . . . . . . . . . . . . . . 23.3
DOT_UML_DETAILS . . . . . . . . . . . . . . . . . . . .23.19 HIDE_UNDOC_CLASSES . . . . . . . . . . . . . . . . . 23.3
DOT_WRAP_THRESHOLD . . . . . . . . . . . . . . . . .23.19 HIDE_UNDOC_MEMBERS . . . . . . . . . . . . . . . . . 23.3
DOXYFILE_ENCODING . . . . . . . . . . . . . . . . . . . 23.2 HIDE_UNDOC_RELATIONS . . . . . . . . . . . . . . . .23.19
ECLIPSE_DOC_ID . . . . . . . . . . . . . . . . . . . . . 23.8 HTML_COLORSTYLE . . . . . . . . . . . . . . . . . . . . 23.8
ENABLED_SECTIONS . . . . . . . . . . . . . . . . . . . 23.3 HTML_COLORSTYLE_GAMMA . . . . . . . . . . . . . . 23.8
ENABLE_PREPROCESSING . . . . . . . . . . . . . . . .23.17 HTML_COLORSTYLE_HUE . . . . . . . . . . . . . . . . 23.8
ENUM_VALUES_PER_LINE . . . . . . . . . . . . . . . . 23.8 HTML_COLORSTYLE_SAT . . . . . . . . . . . . . . . . . 23.8
EXAMPLE_PATH . . . . . . . . . . . . . . . . . . . . . . 23.5 HTML_DYNAMIC_MENUS . . . . . . . . . . . . . . . . . 23.8
EXAMPLE_PATTERNS . . . . . . . . . . . . . . . . . . . 23.5 HTML_DYNAMIC_SECTIONS . . . . . . . . . . . . . . . 23.8
EXAMPLE_RECURSIVE . . . . . . . . . . . . . . . . . . 23.5 HTML_EXTRA_FILES . . . . . . . . . . . . . . . . . . . . 23.8
EXCLUDE . . . . . . . . . . . . . . . . . . . . . . . . . . 23.5 HTML_EXTRA_STYLESHEET . . . . . . . . . . . . . . . 23.8
EXCLUDE_PATTERNS . . . . . . . . . . . . . . . . . . . 23.5 HTML_FILE_EXTENSION . . . . . . . . . . . . . . . . . 23.8
EXCLUDE_SYMBOLS . . . . . . . . . . . . . . . . . . . 23.5 HTML_FOOTER . . . . . . . . . . . . . . . . . . . . . . . 23.8
EXCLUDE_SYMLINKS . . . . . . . . . . . . . . . . . . . 23.5 HTML_FORMULA_FORMAT . . . . . . . . . . . . . . . . 23.8
EXPAND_AS_DEFINED . . . . . . . . . . . . . . . . . . .23.17 HTML_HEADER . . . . . . . . . . . . . . . . . . . . . . . 23.8
EXPAND_ONLY_PREDEF . . . . . . . . . . . . . . . . .23.17 HTML_INDEX_NUM_ENTRIES . . . . . . . . . . . . . . . 23.8
EXTENSION_MAPPING . . . . . . . . . . . . . . . . . . 23.2 HTML_OUTPUT . . . . . . . . . . . . . . . . . . . . . . . 23.8
EXTERNAL_GROUPS . . . . . . . . . . . . . . . . . . .23.18 HTML_STYLESHEET . . . . . . . . . . . . . . . . . . . . 23.8
EXTERNAL_PAGES . . . . . . . . . . . . . . . . . . . . .23.18 IDL_PROPERTY_SUPPORT . . . . . . . . . . . . . . . . 23.2
EXTERNAL_SEARCH . . . . . . . . . . . . . . . . . . . . 23.8 IGNORE_PREFIX . . . . . . . . . . . . . . . . . . . . . . 23.7
EXTERNAL_SEARCH_ID . . . . . . . . . . . . . . . . . . 23.8 IMAGE_PATH . . . . . . . . . . . . . . . . . . . . . . . . 23.5
EXTRACT_ALL . . . . . . . . . . . . . . . . . . . . . . . 23.3 INCLUDED_BY_GRAPH . . . . . . . . . . . . . . . . . .23.19
EXTRACT_ANON_NSPACES . . . . . . . . . . . . . . . . 23.3 INCLUDE_FILE_PATTERNS . . . . . . . . . . . . . . . .23.17
EXTRACT_LOCAL_CLASSES . . . . . . . . . . . . . . . 23.3 INCLUDE_GRAPH . . . . . . . . . . . . . . . . . . . . .23.19
EXTRACT_LOCAL_METHODS . . . . . . . . . . . . . . . 23.3 INCLUDE_PATH . . . . . . . . . . . . . . . . . . . . . . .23.17
EXTRACT_PACKAGE . . . . . . . . . . . . . . . . . . . . 23.3 INHERIT_DOCS . . . . . . . . . . . . . . . . . . . . . . . 23.2
EXTRACT_PRIVATE . . . . . . . . . . . . . . . . . . . . 23.3 INLINE_GROUPED_CLASSES . . . . . . . . . . . . . . . 23.2
EXTRACT_PRIV_VIRTUAL . . . . . . . . . . . . . . . . . 23.3 INLINE_INFO . . . . . . . . . . . . . . . . . . . . . . . . 23.3
EXTRACT_STATIC . . . . . . . . . . . . . . . . . . . . . 23.3 INLINE_INHERITED_MEMB . . . . . . . . . . . . . . . . 23.2
EXTRA_PACKAGES . . . . . . . . . . . . . . . . . . . . 23.9 INLINE_SIMPLE_STRUCTS . . . . . . . . . . . . . . . . 23.2
EXTRA_SEARCH_MAPPINGS . . . . . . . . . . . . . . . 23.8 INLINE_SOURCES . . . . . . . . . . . . . . . . . . . . . 23.6
EXT_LINKS_IN_WINDOW . . . . . . . . . . . . . . . . . 23.8 INPUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23.5
FILE_PATTERNS . . . . . . . . . . . . . . . . . . . . . . 23.5 INPUT_ENCODING . . . . . . . . . . . . . . . . . . . . . 23.5
FILE_VERSION_FILTER . . . . . . . . . . . . . . . . . . 23.3 INPUT_FILE_ENCODING . . . . . . . . . . . . . . . . . . 23.5
FILTER_PATTERNS . . . . . . . . . . . . . . . . . . . . . 23.5 INPUT_FILTER . . . . . . . . . . . . . . . . . . . . . . . 23.5
FILTER_SOURCE_FILES . . . . . . . . . . . . . . . . . . 23.5 INTERACTIVE_SVG . . . . . . . . . . . . . . . . . . . .23.19
FILTER_SOURCE_PATTERNS . . . . . . . . . . . . . . . 23.5 INTERNAL_DOCS . . . . . . . . . . . . . . . . . . . . . 23.3
FORCE_LOCAL_INCLUDES . . . . . . . . . . . . . . . . 23.3 JAVADOC_AUTOBRIEF . . . . . . . . . . . . . . . . . . . 23.2
FORMULA_FONTSIZE . . . . . . . . . . . . . . . . . . . 23.8 JAVADOC_BANNER . . . . . . . . . . . . . . . . . . . . 23.2

23.1 Format 117
LATEX_BATCHMODE . . . . . . . . . . . . . . . . . . . . 23.9 REFERENCES_RELATION . . . . . . . . . . . . . . . . . 23.6

LATEX_BIB_STYLE . . . . . . . . . . . . . . . . . . . . . 23.9 REPEAT_BRIEF . . . . . . . . . . . . . . . . . . . . . . . 23.2
LATEX_CMD_NAME . . . . . . . . . . . . . . . . . . . . 23.9 RESOLVE_UNNAMED_PARAMS . . . . . . . . . . . . . . 23.3
LATEX_EMOJI_DIRECTORY . . . . . . . . . . . . . . . . 23.9 RTF_EXTENSIONS_FILE . . . . . . . . . . . . . . . . . .23.10
LATEX_EXTRA_FILES . . . . . . . . . . . . . . . . . . . 23.9 RTF_HYPERLINKS . . . . . . . . . . . . . . . . . . . . .23.10
LATEX_EXTRA_STYLESHEET . . . . . . . . . . . . . . . 23.9 RTF_OUTPUT . . . . . . . . . . . . . . . . . . . . . . . .23.10
LATEX_FOOTER . . . . . . . . . . . . . . . . . . . . . . 23.9 RTF_STYLESHEET_FILE . . . . . . . . . . . . . . . . . .23.10
LATEX_HEADER . . . . . . . . . . . . . . . . . . . . . . 23.9 SEARCHDATA_FILE . . . . . . . . . . . . . . . . . . . . 23.8
LATEX_HIDE_INDICES . . . . . . . . . . . . . . . . . . . 23.9 SEARCHENGINE . . . . . . . . . . . . . . . . . . . . . . 23.8
LATEX_MAKEINDEX_CMD . . . . . . . . . . . . . . . . . 23.9 SEARCHENGINE_URL . . . . . . . . . . . . . . . . . . . 23.8
LATEX_OUTPUT . . . . . . . . . . . . . . . . . . . . . . 23.9 SEARCH_INCLUDES . . . . . . . . . . . . . . . . . . . .23.17
LAYOUT_FILE . . . . . . . . . . . . . . . . . . . . . . . . 23.3 SEPARATE_MEMBER_PAGES . . . . . . . . . . . . . . . 23.2
LOOKUP_CACHE_SIZE . . . . . . . . . . . . . . . . . . 23.2 SERVER_BASED_SEARCH . . . . . . . . . . . . . . . . 23.8
MACRO_EXPANSION . . . . . . . . . . . . . . . . . . . .23.17 SHORT_NAMES . . . . . . . . . . . . . . . . . . . . . . 23.2
MAKEINDEX_CMD_NAME . . . . . . . . . . . . . . . . . 23.9 SHOW_FILES . . . . . . . . . . . . . . . . . . . . . . . . 23.3
MAN_EXTENSION . . . . . . . . . . . . . . . . . . . . .23.11 SHOW_GROUPED_MEMB_INC . . . . . . . . . . . . . . 23.3
MAN_LINKS . . . . . . . . . . . . . . . . . . . . . . . . .23.11 SHOW_HEADERFILE . . . . . . . . . . . . . . . . . . . . 23.3
MAN_OUTPUT . . . . . . . . . . . . . . . . . . . . . . .23.11 SHOW_INCLUDE_FILES . . . . . . . . . . . . . . . . . . 23.3
MAN_SUBDIR . . . . . . . . . . . . . . . . . . . . . . . .23.11 SHOW_NAMESPACES . . . . . . . . . . . . . . . . . . . 23.3
MARKDOWN_ID_STYLE . . . . . . . . . . . . . . . . . . 23.2 SHOW_USED_FILES . . . . . . . . . . . . . . . . . . . . 23.3
MARKDOWN_SUPPORT . . . . . . . . . . . . . . . . . . 23.2 SIP_SUPPORT . . . . . . . . . . . . . . . . . . . . . . . 23.2
MATHJAX_CODEFILE . . . . . . . . . . . . . . . . . . . 23.8 SITEMAP_URL . . . . . . . . . . . . . . . . . . . . . . . 23.8
MATHJAX_EXTENSIONS . . . . . . . . . . . . . . . . . . 23.8 SKIP_FUNCTION_MACROS . . . . . . . . . . . . . . . .23.17
MATHJAX_FORMAT . . . . . . . . . . . . . . . . . . . . 23.8 SORT_BRIEF_DOCS . . . . . . . . . . . . . . . . . . . . 23.3
MATHJAX_RELPATH . . . . . . . . . . . . . . . . . . . . 23.8 SORT_BY_SCOPE_NAME . . . . . . . . . . . . . . . . . 23.3
MATHJAX_VERSION . . . . . . . . . . . . . . . . . . . . 23.8
SORT_GROUP_NAMES . . . . . . . . . . . . . . . . . . 23.3
MAX_DOT_GRAPH_DEPTH . . . . . . . . . . . . . . . .23.19
SORT_MEMBERS_CTORS_1ST . . . . . . . . . . . . . . 23.3
MAX_INITIALIZER_LINES . . . . . . . . . . . . . . . . . 23.3
SORT_MEMBER_DOCS . . . . . . . . . . . . . . . . . . 23.3
MSCFILE_DIRS . . . . . . . . . . . . . . . . . . . . . . .23.19
SOURCE_BROWSER . . . . . . . . . . . . . . . . . . . . 23.6
MSCGEN_TOOL . . . . . . . . . . . . . . . . . . . . . .23.19
SOURCE_TOOLTIPS . . . . . . . . . . . . . . . . . . . . 23.6
MULTILINE_CPP_IS_BRIEF . . . . . . . . . . . . . . . . 23.2
SQLITE3_OUTPUT . . . . . . . . . . . . . . . . . . . . .23.15
NUM_PROC_THREADS . . . . . . . . . . . . . . . . . . 23.2
SQLITE3_RECREATE_DB . . . . . . . . . . . . . . . . .23.15
OBFUSCATE_EMAILS . . . . . . . . . . . . . . . . . . . 23.8
STRICT_PROTO_MATCHING . . . . . . . . . . . . . . . 23.3
OPTIMIZE_FOR_FORTRAN . . . . . . . . . . . . . . . . 23.2
STRIP_CODE_COMMENTS . . . . . . . . . . . . . . . . 23.6
OPTIMIZE_OUTPUT_FOR_C . . . . . . . . . . . . . . . . 23.2
STRIP_FROM_INC_PATH . . . . . . . . . . . . . . . . . 23.2
OPTIMIZE_OUTPUT_JAVA . . . . . . . . . . . . . . . . . 23.2
STRIP_FROM_PATH . . . . . . . . . . . . . . . . . . . . 23.2
OPTIMIZE_OUTPUT_SLICE . . . . . . . . . . . . . . . . 23.2
SUBGROUPING . . . . . . . . . . . . . . . . . . . . . . . 23.2
OPTIMIZE_OUTPUT_VHDL . . . . . . . . . . . . . . . . 23.2
TAB_SIZE . . . . . . . . . . . . . . . . . . . . . . . . . . 23.2
OUTPUT_DIRECTORY . . . . . . . . . . . . . . . . . . . 23.2
TAGFILES . . . . . . . . . . . . . . . . . . . . . . . . . .23.18
OUTPUT_LANGUAGE . . . . . . . . . . . . . . . . . . . 23.2
TEMPLATE_RELATIONS . . . . . . . . . . . . . . . . . .23.19
PAPER_TYPE . . . . . . . . . . . . . . . . . . . . . . . . 23.9
PDF_HYPERLINKS . . . . . . . . . . . . . . . . . . . . . 23.9 TIMESTAMP . . . . . . . . . . . . . . . . . . . . . . . . . 23.2
PERLMOD_LATEX . . . . . . . . . . . . . . . . . . . . .23.16 TOC_EXPAND . . . . . . . . . . . . . . . . . . . . . . . . 23.8
PERLMOD_MAKEVAR_PREFIX . . . . . . . . . . . . . .23.16 TOC_INCLUDE_HEADINGS . . . . . . . . . . . . . . . . 23.2
PERLMOD_PRETTY . . . . . . . . . . . . . . . . . . . .23.16 TREEVIEW_WIDTH . . . . . . . . . . . . . . . . . . . . . 23.8
PLANTUML_CFG_FILE . . . . . . . . . . . . . . . . . . .23.19 TYPEDEF_HIDES_STRUCT . . . . . . . . . . . . . . . . 23.2
PLANTUML_INCLUDE_PATH . . . . . . . . . . . . . . . .23.19 UML_LIMIT_NUM_FIELDS . . . . . . . . . . . . . . . . .23.19
PLANTUML_JAR_PATH . . . . . . . . . . . . . . . . . . .23.19 UML_LOOK . . . . . . . . . . . . . . . . . . . . . . . . .23.19
PREDEFINED . . . . . . . . . . . . . . . . . . . . . . . .23.17 USE_HTAGS . . . . . . . . . . . . . . . . . . . . . . . . 23.6
PROJECT_BRIEF . . . . . . . . . . . . . . . . . . . . . . 23.2 USE_MATHJAX . . . . . . . . . . . . . . . . . . . . . . . 23.8
PROJECT_LOGO . . . . . . . . . . . . . . . . . . . . . . 23.2 USE_MDFILE_AS_MAINPAGE . . . . . . . . . . . . . . . 23.5
PROJECT_NAME . . . . . . . . . . . . . . . . . . . . . . 23.2 USE_PDFLATEX . . . . . . . . . . . . . . . . . . . . . . 23.9
PROJECT_NUMBER . . . . . . . . . . . . . . . . . . . . 23.2 VERBATIM_HEADERS . . . . . . . . . . . . . . . . . . . 23.6
PYTHON_DOCSTRING . . . . . . . . . . . . . . . . . . . 23.2 WARNINGS . . . . . . . . . . . . . . . . . . . . . . . . . 23.4
QCH_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . 23.8 WARN_AS_ERROR . . . . . . . . . . . . . . . . . . . . . 23.4
QHG_LOCATION . . . . . . . . . . . . . . . . . . . . . . 23.8 WARN_FORMAT . . . . . . . . . . . . . . . . . . . . . . 23.4
QHP_CUST_FILTER_ATTRS . . . . . . . . . . . . . . . . 23.8 WARN_IF_DOC_ERROR . . . . . . . . . . . . . . . . . . 23.4
QHP_CUST_FILTER_NAME . . . . . . . . . . . . . . . . 23.8 WARN_IF_INCOMPLETE_DOC . . . . . . . . . . . . . . 23.4
QHP_NAMESPACE . . . . . . . . . . . . . . . . . . . . . 23.8 WARN_IF_UNDOCUMENTED . . . . . . . . . . . . . . . 23.4
QHP_SECT_FILTER_ATTRS . . . . . . . . . . . . . . . . 23.8 WARN_IF_UNDOC_ENUM_VAL . . . . . . . . . . . . . . 23.4
QHP_VIRTUAL_FOLDER . . . . . . . . . . . . . . . . . . 23.8 WARN_LINE_FORMAT . . . . . . . . . . . . . . . . . . . 23.4
QT_AUTOBRIEF . . . . . . . . . . . . . . . . . . . . . . 23.2 WARN_LOGFILE . . . . . . . . . . . . . . . . . . . . . . 23.4
QUIET . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23.4 WARN_NO_PARAMDOC . . . . . . . . . . . . . . . . . . 23.4
RECURSIVE . . . . . . . . . . . . . . . . . . . . . . . . . 23.5 XML_NS_MEMB_FILE_SCOPE . . . . . . . . . . . . . .23.12
REFERENCED_BY_RELATION . . . . . . . . . . . . . . 23.6 XML_OUTPUT . . . . . . . . . . . . . . . . . . . . . . .23.12
REFERENCES_LINK_SOURCE . . . . . . . . . . . . . . 23.6 XML_PROGRAMLISTING . . . . . . . . . . . . . . . . . .23.12

118 Configuration
23.2 Project related configuration options
DOXYFILE_ENCODING This tag specifies the encoding used for all characters in the configuration file that follow.
The default is UTF-8 which is also the encoding used for all text before the first occurrence of this tag.
Doxygen uses libiconv (or the iconv built into libc) for the transcoding. See https://www.←-
gnu.org/software/libiconv/ for the list of possible encodings.
The default value is: UTF-8.
PROJECT_NAME The PROJECT_NAME tag is a single word (or a sequence of words surrounded by double-
quotes, unless you are using Doxywizard) that should identify the project for which the documentation is
generated. This name is used in the title of most generated pages and in a few other places.
The default value is: My Project.
PROJECT_NUMBER The PROJECT_NUMBER tag can be used to enter a project or revision number. This could
be handy for archiving the generated documentation or if some version control system is used.
PROJECT_BRIEF Using the PROJECT_BRIEF tag one can provide an optional one line description for a project
that appears at the top of each page and should give viewer a quick idea about the purpose of the project.
Keep the description short.
PROJECT_LOGO With the PROJECT_LOGO tag one can specify a logo or an icon that is included in the docu-
mentation. The maximum height of the logo should not exceed 55 pixels and the maximum width should not
exceed 200 pixels. Doxygen will copy the logo to the output directory.
OUTPUT_DIRECTORY The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path into
which the generated documentation will be written. If a relative path is entered, it will be relative to the
location where doxygen was started. If left blank the current directory will be used.
CREATE_SUBDIRS If the CREATE_SUBDIRS tag is set to YES then doxygen will create up to 4096 sub-
directories (in 2 levels) under the output directory of each output format and will distribute the generated
files over these directories. Enabling this option can be useful when feeding doxygen a huge amount of
source files, where putting all generated files in the same directory would otherwise causes performance
problems for the file system. Adapt CREATE_SUBDIRS_LEVEL to control the number of sub-directories.
The default value is: NO.
CREATE_SUBDIRS_LEVEL Controls the number of sub-directories that will be created when CREATE_←-
SUBDIRS tag is set to YES. Level 0 represents 16 directories, and every level increment doubles the number
of directories, resulting in 4096 directories at level 8 which is the default and also the maximum value. The
sub-directories are organized in 2 levels, the first level always has a fixed number of 16 directories.
Minimum value: 0, maximum value: 8, default value: 8.
This tag requires that the tag CREATE_SUBDIRS is set to YES.
ALLOW_UNICODE_NAMES If the ALLOW_UNICODE_NAMES tag is set to YES, doxygen will allow non-ASCII
characters to appear in the names of generated files. If set to NO, non-ASCII characters will be escaped, for
example _xE3_x81_x84 will be used for Unicode U+3044.
OUTPUT_LANGUAGE The OUTPUT_LANGUAGE tag is used to specify the language in which all documentation
generated by doxygen is written. Doxygen will use this information to generate all constant output in the
proper language.
Possible values are: Afrikaans, Arabic, Armenian, Brazilian, Bulgarian, Catalan,
Chinese, Chinese-Traditional, Croatian, Czech, Danish, Dutch, English (United
States), Esperanto, Farsi (Persian), Finnish, French, German, Greek, Hindi, Hungarian,
Indonesian, Italian, Japanese, Japanese-en (Japanese with English messages), Korean,
Korean-en (Korean with English messages), Latvian, Lithuanian, Macedonian, Norwegian,
Persian (Farsi), Polish, Portuguese, Romanian, Russian, Serbian, Serbian-Cyrillic,
Slovak, Slovene, Spanish, Swedish, Turkish, Ukrainian and Vietnamese.
The default value is: English.

23.2 Project related configuration options 119
BRIEF_MEMBER_DESC If the BRIEF_MEMBER_DESC tag is set to YES, doxygen will include brief member
descriptions after the members that are listed in the file and class documentation (similar to Javadoc). Set
to NO to disable this.
The default value is: YES.
REPEAT_BRIEF If the REPEAT_BRIEF tag is set to YES, doxygen will prepend the brief description of a mem-
ber or function before the detailed description
Note: If both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the brief descriptions
will be completely suppressed.
ABBREVIATE_BRIEF This tag implements a quasi-intelligent brief description abbreviator that is used to form
the text in various listings. Each string in this list, if found as the leading text of the brief description, will be
stripped from the text and the result, after processing the whole list, is used as the annotated text. Otherwise,
the brief description is used as-is. If left blank, the following values are used ($name is automatically re-
placed with the name of the entity): The $name class, The $name widget, The $name file,
is, provides, specifies, contains, represents, a, an and the.
ALWAYS_DETAILED_SEC If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES
then doxygen will generate a detailed section even if there is only a brief description.
INLINE_INHERITED_MEMB If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all
inherited members of a class in the documentation of that class as if those members were ordinary class
members. Constructors, destructors and assignment operators of the base classes will not be shown.
FULL_PATH_NAMES If the FULL_PATH_NAMES tag is set to YES, doxygen will prepend the full path before
files name in the file list and in the header files. If set to NO the shortest path that makes the file name unique
will be used
STRIP_FROM_PATH The STRIP_FROM_PATH tag can be used to strip a user-defined part of the path. Strip-
ping is only done if one of the specified strings matches the left-hand part of the path. The tag can be used
to show relative paths in the file list. If left blank the directory from which doxygen is run is used as the path
to strip.
Note that you can specify absolute paths here, but also relative paths, which will be relative from the directory
where doxygen is started.
This tag requires that the tag FULL_PATH_NAMES is set to YES.
STRIP_FROM_INC_PATH The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of the
path mentioned in the documentation of a class, which tells the reader which header file to include in order
to use a class. If left blank only the name of the header file containing the class definition is used. Otherwise
one should specify the list of include paths that are normally passed to the compiler using the -I flag.
SHORT_NAMES If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter (but less readable)
file names. This can be useful is your file systems doesn't support long names like on DOS, Mac, or CD-ROM.
JAVADOC_AUTOBRIEF If the JAVADOC_AUTOBRIEF tag is set to YES then doxygen will interpret the first line
(until the first dot) of a Javadoc-style comment as the brief description. If set to NO, the Javadoc-style will
behave just like regular Qt-style comments (thus requiring an explicit @brief command for a brief description.)
JAVADOC_BANNER If the JAVADOC_BANNER tag is set to YES then doxygen will interpret a line such as
/***************
as being the beginning of a Javadoc-style comment ¨banner¨. If set to NO, the Javadoc-style will behave just
like regular comments and it will not be interpreted by doxygen.

120 Configuration
QT_AUTOBRIEF If the QT_AUTOBRIEF tag is set to YES then doxygen will interpret the first line (until the first
dot) of a Qt-style comment as the brief description. If set to NO, the Qt-style will behave just like regular
Qt-style comments (thus requiring an explicit \brief command for a brief description.)
MULTILINE_CPP_IS_BRIEF The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make doxygen

treat a multi-line C++ special comment block (i.e. a block of //! or /// comments) as a brief description.
This used to be the default behavior. The new default is to treat a multi-line C++ comment block as a detailed
description. Set this tag to YES if you prefer the old behavior instead.
Note that setting this tag to YES also means that rational rose comments are not recognized any more.
PYTHON_DOCSTRING By default Python docstrings are displayed as preformatted text and doxygen's special
commands cannot be used. By setting PYTHON_DOCSTRING to NO the doxygen's special commands can
be used and the contents of the docstring documentation blocks is shown as doxygen documentation.
INHERIT_DOCS If the INHERIT_DOCS tag is set to YES then an undocumented member inherits the docu-
mentation from any documented member that it re-implements.
SEPARATE_MEMBER_PAGES If the SEPARATE_MEMBER_PAGES tag is set to YES then doxygen will produce
a new page for each member. If set to NO, the documentation of a member will be part of the file/class/-
namespace that contains it.
TAB_SIZE The TAB_SIZE tag can be used to set the number of spaces in a tab. Doxygen uses this value to
replace tabs by spaces in code fragments.
ALIASES This tag can be used to specify a number of aliases that act as commands in the documentation. An
alias has the form:
name=value
For example adding
"sideeffect=@par Side Effects:^^"
will allow you to put the command \sideeffect (or @sideeffect) in the documentation, which will
result in a user-defined paragraph with heading ¨Side Effects:¨. Note that you cannot put \n's in the value part
of an alias to insert newlines (in the resulting output). You can put ∧∧ in the value part of an alias to insert a
newline as if a physical newline was in the original file. When you need a literal { or } or , in the value part of
an alias you have to escape them by means of a backslash (\), this can lead to conflicts with the commands
\{ and \} for these it is advised to use the version @{ and @} or use a double escape (\\{ and \\})
OPTIMIZE_OUTPUT_FOR_C Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C
sources only. Doxygen will then generate output that is more tailored for C. For instance, some of the names
that are used will be different. The list of all members will be omitted, etc.
OPTIMIZE_OUTPUT_JAVA Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java or
Python sources only. Doxygen will then generate output that is more tailored for that language. For instance,
namespaces will be presented as packages, qualified scopes will look different, etc.
OPTIMIZE_FOR_FORTRAN Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran
sources. Doxygen will then generate output that is tailored for Fortran.

23.2 Project related configuration options 121
OPTIMIZE_OUTPUT_VHDL Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL
sources. Doxygen will then generate output that is tailored for VHDL.
OPTIMIZE_OUTPUT_SLICE Set the OPTIMIZE_OUTPUT_SLICE tag to YES if your project consists of Slice
sources only. Doxygen will then generate output that is more tailored for that language. For instance, names-
paces will be presented as modules, types will be separated into more groups, etc.
EXTENSION_MAPPING Doxygen selects the parser to use depending on the extension of the files it parses.
With this tag you can assign which parser to use for a given extension. Doxygen has a built-in mapping, but
you can override or extend it using this tag. The format is ext=language, where ext is a file extension,
and language is one of the parsers supported by doxygen: IDL, Java, JavaScript, Csharp (C#), C, C++, Lex,
D, PHP, md (Markdown), Objective-C, Python, Slice, VHDL, Fortran (fixed format Fortran: FortranFixed, free
formatted Fortran: FortranFree, unknown formatted Fortran: Fortran. In the later case the parser tries to
guess whether the code is fixed or free formatted code, this is the default for Fortran type files).
For instance to make doxygen treat .inc files as Fortran files (default is PHP), and .f files as C (default is
Fortran), use: inc=Fortran f=C.
Note: For files without extension you can use no_extension as a placeholder.
Note that for custom extensions you also need to set FILE_PATTERNS otherwise the files are not read by
doxygen. When specifying no_extension you should add ∗ to the FILE_PATTERNS.
Note see also the list of default file extension mappings.
MARKDOWN_SUPPORT If the MARKDOWN_SUPPORT tag is enabled then doxygen pre-processes all com-
ments according to the Markdown format, which allows for more readable documentation. See https←-
://daringfireball.net/projects/markdown/ for details. The output of markdown processing
is further processed by doxygen, so you can mix doxygen, HTML, and XML commands with Markdown for-
matting. Disable only in case of backward compatibilities issues.
TOC_INCLUDE_HEADINGS When the TOC_INCLUDE_HEADINGS tag is set to a non-zero value, all headings
up to that level are automatically included in the table of contents, even if they do not have an id attribute.
Note
This feature currently applies only to Markdown headings.

This tag requires that the tag MARKDOWN_SUPPORT is set to YES.
MARKDOWN_ID_STYLE The MARKDOWN_ID_STYLE tag can be used to specify the algorithm used to generate
identifiers for the Markdown headings. Note: Every identifier is unique.
Possible values are: DOXYGEN Use a fixed 'autotoc_md' string followed by a sequence number starting at
0. and GITHUB Use the lower case version of title with any whitespace replaced by '-' and punctations
characters removed..
The default value is: DOXYGEN.
This tag requires that the tag MARKDOWN_SUPPORT is set to YES.
AUTOLINK_SUPPORT When enabled doxygen tries to link words that correspond to documented classes, or
namespaces to their corresponding documentation. Such a link can be prevented in individual cases by
putting a % sign in front of the word or globally by setting AUTOLINK_SUPPORT to NO.
BUILTIN_STL_SUPPORT If you use STL classes (i.e. std::string, std::vector, etc.) but do not want
to include (a tag file for) the STL sources as input, then you should set this tag to YES in order to let doxy-
gen match functions declarations and definitions whose arguments contain STL classes (e.g. func(std←-
::string); versus func(std::string) {}). This also make the inheritance and collaboration dia-
grams that involve STL classes more complete and accurate.

122 Configuration
CPP_CLI_SUPPORT If you use Microsoft's C++/CLI language, you should set this option to YES to enable pars-
ing support.
SIP_SUPPORT Set the SIP_SUPPORT tag to YES if your project consists of sip sources only. Doxygen will
parse them like normal C++ but will assume all classes use public instead of private inheritance when no
explicit protection keyword is present.
IDL_PROPERTY_SUPPORT For Microsoft's IDL there are propget and propput attributes to indicate getter
and setter methods for a property. Setting this option to YES will make doxygen to replace the get and set
methods by a property in the documentation. This will only work if the methods are indeed getting or setting
a simple type. If this is not the case, or you want to show the methods anyway, you should set this option to
NO.
DISTRIBUTE_GROUP_DOC If member grouping is used in the documentation and the DISTRIBUTE_←-

GROUP_DOC tag is set to YES then doxygen will reuse the documentation of the first member in the group (if
any) for the other members of the group. By default all members of a group must be documented explicitly.
GROUP_NESTED_COMPOUNDS If one adds a struct or class to a group and this option is enabled, then also any
nested class or struct is added to the same group. By default this option is disabled and one has to add
nested compounds explicitly via \ingroup.
SUBGROUPING Set the SUBGROUPING tag to YES to allow class member groups of the same type (for instance
a group of public functions) to be put as a subgroup of that type (e.g. under the Public Functions section). Set
it to NO to prevent subgrouping. Alternatively, this can be done per class using the \nosubgrouping command.
INLINE_GROUPED_CLASSES When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs

and unions are shown inside the group in which they are included (e.g. using \ingroup) instead of on a
separate page (for HTML and Man pages) or section (for LATEX and RTF).
Note that this feature does not work in combination with SEPARATE_MEMBER_PAGES.
INLINE_SIMPLE_STRUCTS When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and
unions with only public data fields or simple typedef fields will be shown inline in the documentation of the
scope in which they are defined (i.e. file, namespace, or group documentation), provided this scope is docu-
mented. If set to NO, structs, classes, and unions are shown on a separate page (for HTML and Man pages)
or section (for LATEX and RTF).
TYPEDEF_HIDES_STRUCT When TYPEDEF_HIDES_STRUCT tag is enabled, a typedef of a struct, union,

or enum is documented as struct, union, or enum with the name of the typedef. So typedef struct
TypeS {} TypeT, will appear in the documentation as a struct with name TypeT. When disabled the
typedef will appear as a member of a file, namespace, or class. And the struct will be named TypeS.
This can typically be useful for C code in case the coding convention dictates that all compound types are
typedef'ed and only the typedef is referenced, never the tag name.
LOOKUP_CACHE_SIZE The size of the symbol lookup cache can be set using LOOKUP_CACHE_SIZE. This
cache is used to resolve symbols given their name and scope. Since this can be an expensive process and
often the same symbol appears multiple times in the code, doxygen keeps a cache of pre-resolved symbols.
If the cache is too small doxygen will become slower. If the cache is too large, memory is wasted. The
cache size is given by this formula: 2(16+LOOKUP_CACHE_SIZE) . The valid range is 0..9, the default is 0,
corresponding to a cache size of 216 = 65536 symbols. At the end of a run doxygen will report the cache
usage and suggest the optimal cache size from a speed point of view.

23.3 Build related configuration options 123
NUM_PROC_THREADS The NUM_PROC_THREADS specifies the number of threads doxygen is allowed to use
during processing. When set to 0 doxygen will based this on the number of cores available in the system.
You can set it explicitly to a value larger than 0 to get more control over the balance between CPU load and
processing speed. At this moment only the input processing can be done using multiple threads. Since this
is still an experimental feature the default is set to 1, which effectively disables parallel processing. Please
report any issues you encounter. Generating dot graphs in parallel is controlled by the DOT_NUM_THREADS
setting.
TIMESTAMP If the TIMESTAMP tag is set different from NO then each generated page will contain the date or
date and time when the page was generated. Setting this to NO can help when comparing the output of
multiple runs.
Possible values are: YES, NO, DATETIME and DATE.
23.3 Build related configuration options
EXTRACT_ALL If the EXTRACT_ALL tag is set to YES, doxygen will assume all entities in documentation are
documented, even if no documentation was available. Private class members and static file members will be
hidden unless the EXTRACT_PRIVATE respectively EXTRACT_STATIC tags are set to YES.
Note
This will also disable the warnings about undocumented members that are normally produced when
WARNINGS is set to YES.
EXTRACT_PRIVATE If the EXTRACT_PRIVATE tag is set to YES, all private members of a class will be in-
cluded in the documentation.
EXTRACT_PRIV_VIRTUAL If the EXTRACT_PRIV_VIRTUAL tag is set to YES, documented private virtual

methods of a class will be included in the documentation.
EXTRACT_PACKAGE If the EXTRACT_PACKAGE tag is set to YES, all members with package or internal scope
will be included in the documentation.
EXTRACT_STATIC If the EXTRACT_STATIC tag is set to YES, all static members of a file will be included in
the documentation.
EXTRACT_LOCAL_CLASSES If the EXTRACT_LOCAL_CLASSES tag is set to YES, classes (and structs) de-
fined locally in source files will be included in the documentation. If set to NO, only classes defined in header
files are included. Does not have any effect for Java sources.
EXTRACT_LOCAL_METHODS This flag is only useful for Objective-C code. If set to YES, local methods, which
are defined in the implementation section but not in the interface are included in the documentation. If set to
NO, only methods in the interface are included.
EXTRACT_ANON_NSPACES If this flag is set to YES, the members of anonymous namespaces will be extracted
and appear in the documentation as a namespace called 'anonymous_namespace{file}', where file will be
replaced with the base name of the file that contains the anonymous namespace. By default anonymous
namespace are hidden.

124 Configuration
RESOLVE_UNNAMED_PARAMS If this flag is set to YES, the name of an unnamed parameter in a declaration
will be determined by the corresponding definition. By default unnamed parameters remain unnamed in the
output.
HIDE_UNDOC_MEMBERS If the HIDE_UNDOC_MEMBERS tag is set to YES, doxygen will hide all undocumented
members inside documented classes or files. If set to NO these members will be included in the various
overviews, but no documentation section is generated. This option has no effect if EXTRACT_ALL is enabled.
HIDE_UNDOC_CLASSES If the HIDE_UNDOC_CLASSES tag is set to YES, doxygen will hide all undocumented
classes that are normally visible in the class hierarchy. If set to NO, these classes will be included in the
various overviews. This option will also hide undocumented C++ concepts if enabled. This option has no
effect if EXTRACT_ALL is enabled.
HIDE_FRIEND_COMPOUNDS If the HIDE_FRIEND_COMPOUNDS tag is set to YES, doxygen will hide all friend
declarations. If set to NO, these declarations will be included in the documentation.
HIDE_IN_BODY_DOCS If the HIDE_IN_BODY_DOCS tag is set to YES, doxygen will hide any documentation
blocks found inside the body of a function. If set to NO, these blocks will be appended to the function's detailed
documentation block.
INTERNAL_DOCS The INTERNAL_DOCS tag determines if documentation that is typed after a \internal com-
mand is included. If the tag is set to NO then the documentation will be excluded. Set it to YES to include the
internal documentation.
CASE_SENSE_NAMES With the correct setting of option CASE_SENSE_NAMES doxygen will better be able to
match the capabilities of the underlying filesystem.
In case the filesystem is case sensitive (i.e. it supports files in the same directory whose names only differ in
casing), the option must be set to YES to properly deal with such files in case they appear in the input.
For filesystems that are not case sensitive the option should be set to NO to properly deal with output files
written for symbols that only differ in casing, such as for two classes, one named CLASS and the other named
Class, and to also support references to files without having to specify the exact matching casing.
On Windows (including Cygwin) and MacOS, users should typically set this option to NO, whereas on Linux
or other Unix flavors it should typically be set to YES.
Possible values are: SYSTEM, NO and YES.
The default value is: SYSTEM.
HIDE_SCOPE_NAMES If the HIDE_SCOPE_NAMES tag is set to NO then doxygen will show members with their
full class and namespace scopes in the documentation. If set to YES, the scope will be hidden.
HIDE_COMPOUND_REFERENCE If the HIDE_COMPOUND_REFERENCE tag is set to NO (default) then doxygen

will append additional text to a page's title, such as Class Reference. If set to YES the compound reference
will be hidden.
SHOW_HEADERFILE If the SHOW_HEADERFILE tag is set to YES then the documentation for a class will show
which file needs to be included to use the class.
SHOW_INCLUDE_FILES If the SHOW_INCLUDE_FILES tag is set to YES then doxygen will put a list of the
files that are included by a file in the documentation of that file.

23.3 Build related configuration options 125
SHOW_GROUPED_MEMB_INC If the SHOW_GROUPED_MEMB_INC tag is set to YES then Doxygen will add for
each grouped member an include statement to the documentation, telling the reader which file to include in
order to use the member.
FORCE_LOCAL_INCLUDES If the FORCE_LOCAL_INCLUDES tag is set to YES then doxygen will list include
files with double quotes in the documentation rather than with sharp brackets.
INLINE_INFO If the INLINE_INFO tag is set to YES then a tag [inline] is inserted in the documentation for
inline members.
SORT_MEMBER_DOCS If the SORT_MEMBER_DOCS tag is set to YES then doxygen will sort the (detailed) doc-
umentation of file and class members alphabetically by member name. If set to NO, the members will appear
in declaration order.
SORT_BRIEF_DOCS If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the brief descriptions
of file, namespace and class members alphabetically by member name. If set to NO, the members will appear
in declaration order. Note that this will also influence the order of the classes in the class list.
SORT_MEMBERS_CTORS_1ST If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen will sort
the (brief and detailed) documentation of class members so that constructors and destructors are listed
first. If set to NO the constructors will appear in the respective orders defined by SORT_BRIEF_DOCS and
SORT_MEMBER_DOCS.
Note
If SORT_BRIEF_DOCS is set to NO this option is ignored for sorting brief member documentation.
If SORT_MEMBER_DOCS is set to NO this option is ignored for sorting detailed member documenta-
tion.
SORT_GROUP_NAMES If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the hierarchy of
group names into alphabetical order. If set to NO the group names will appear in their defined order.
SORT_BY_SCOPE_NAME If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be sorted by fully-
qualified names, including namespaces. If set to NO, the class list will be sorted only by class name, not
including the namespace part.
Note
This option is not very useful if HIDE_SCOPE_NAMES is set to YES.

This option applies only to the class list, not to the alphabetical list.
STRICT_PROTO_MATCHING If the STRICT_PROTO_MATCHING option is enabled and doxygen fails to do

proper type resolution of all parameters of a function it will reject a match between the prototype and the
implementation of a member function even if there is only one candidate or it is obvious which candidate to
choose by doing a simple string match. By disabling STRICT_PROTO_MATCHING doxygen will still accept
a match between prototype and implementation in such cases.
GENERATE_TODOLIST The GENERATE_TODOLIST tag can be used to enable (YES) or disable (NO) the todo
list. This list is created by putting \todo commands in the documentation.

126 Configuration
GENERATE_TESTLIST The GENERATE_TESTLIST tag can be used to enable (YES) or disable (NO) the test
list. This list is created by putting \test commands in the documentation.
GENERATE_BUGLIST The GENERATE_BUGLIST tag can be used to enable (YES) or disable (NO) the bug list.
This list is created by putting \bug commands in the documentation.
GENERATE_DEPRECATEDLIST The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or

disable (NO) the deprecated list. This list is created by putting \deprecated commands in the documentation.
ENABLED_SECTIONS The ENABLED_SECTIONS tag can be used to enable conditional documentation sec-
tions, marked by \if <section_label> ... \endif and \cond <section_label> ... \endcond blocks.
MAX_INITIALIZER_LINES The MAX_INITIALIZER_LINES tag determines the maximum number of

lines that the initial value of a variable or macro / define can have for it to appear in the documentation.
If the initializer consists of more lines than specified here it will be hidden. Use a value of 0 to hide initializers
completely. The appearance of the value of individual variables and macros / defines can be controlled using
\showinitializer or \hideinitializer command in the documentation regardless of this setting.
SHOW_USED_FILES Set the SHOW_USED_FILES tag to NO to disable the list of files generated at the bottom
of the documentation of classes and structs. If set to YES, the list will mention the files that were used to
generate the documentation.
SHOW_FILES Set the SHOW_FILES tag to NO to disable the generation of the Files page. This will remove the
Files entry from the Quick Index and from the Folder Tree View (if specified).
SHOW_NAMESPACES Set the SHOW_NAMESPACES tag to NO to disable the generation of the Namespaces
page. This will remove the Namespaces entry from the Quick Index and from the Folder Tree View (if speci-
fied).
FILE_VERSION_FILTER The FILE_VERSION_FILTER tag can be used to specify a program or script that
doxygen should invoke to get the current version for each file (typically from the version control system).
Doxygen will invoke the program by executing (via popen()) the command command input-file,
where command is the value of the FILE_VERSION_FILTER tag, and input-file is the name of an
input file provided by doxygen. Whatever the program writes to standard output is used as the file version.
Example of using a shell script as a filter for Unix:
FILE_VERSION_FILTER = "/bin/sh versionfilter.sh"
Example shell script for CVS:
#!/bin/sh
cvs status $1 | sed -n ’s/^[ \]*Working revision:[ \t]*$[0-9][0-9\.]*$.*/\1/p’
Example shell script for Subversion:
#!/bin/sh
svn stat -v $1 | sed -n ’s/^[ A-Z?\*|!]\{1,15\}/r/;s/ \{1,15\}/\/r/;s/ .*//p’
Example filter for ClearCase:
FILE_VERSION_FILTER = "cleartool desc -fmt \%Vn"

23.4 Configuration options related to warning and progress messages 127
LAYOUT_FILE The LAYOUT_FILE tag can be used to specify a layout file which will be parsed by doxygen.
The layout file controls the global structure of the generated output files in an output format independent
way. To create the layout file that represents doxygen's defaults, run doxygen with the -l option. You can
optionally specify a file name after the option, if omitted DoxygenLayout.xml will be used as the name
of the layout file. See also section Changing the layout of pages for information.
Note that if you run doxygen from a directory containing a file called DoxygenLayout.xml, doxygen will
parse it automatically even if the LAYOUT_FILE tag is left empty.
CITE_BIB_FILES The CITE_BIB_FILES tag can be used to specify one or more bib files containing the
reference definitions. This must be a list of .bib files. The .bib extension is automatically appended if omit-
ted. This requires the bibtex tool to be installed. See also https://en.wikipedia.org/wiki/←-
BibTeX for more info. For LATEX the style of the bibliography can be controlled using LATEX_BIB_STYLE.
To use this feature you need bibtex and perl available in the search path. See also \cite for info how to
create references.
23.4 Configuration options related to warning and progress messages
QUIET The QUIET tag can be used to turn on/off the messages that are generated to standard output by doxygen.
If QUIET is set to YES this implies that the messages are off.
WARNINGS The WARNINGS tag can be used to turn on/off the warning messages that are generated to standard
error (stderr) by doxygen. If WARNINGS is set to YES this implies that the warnings are on.
Tip: Turn warnings on while writing the documentation.
WARN_IF_UNDOCUMENTED If the WARN_IF_UNDOCUMENTED tag is set to YES then doxygen will generate
warnings for undocumented members. If EXTRACT_ALL is set to YES then this flag will automatically be
disabled.
WARN_IF_DOC_ERROR If the WARN_IF_DOC_ERROR tag is set to YES, doxygen will generate warnings for
potential errors in the documentation, such as documenting some parameters in a documented function
twice, or documenting parameters that don't exist or using markup commands wrongly.
WARN_IF_INCOMPLETE_DOC If WARN_IF_INCOMPLETE_DOC is set to YES, doxygen will warn about in-

complete function parameter documentation. If set to NO, doxygen will accept that some parameters have no
documentation without warning.
WARN_NO_PARAMDOC This WARN_NO_PARAMDOC option can be enabled to get warnings for functions that are
documented, but have no documentation for their parameters or return value. If set to NO, doxygen will only
warn about wrong parameter documentation, but not about the absence of documentation. If EXTRACT_ALL
is set to YES then this flag will automatically be disabled. See also WARN_IF_INCOMPLETE_DOC
WARN_IF_UNDOC_ENUM_VAL If WARN_IF_UNDOC_ENUM_VAL option is set to YES, doxygen will warn about

undocumented enumeration values. If set to NO, doxygen will accept undocumented enumeration values. If
EXTRACT_ALL is set to YES then this flag will automatically be disabled.
WARN_AS_ERROR If the WARN_AS_ERROR tag is set to YES then doxygen will immediately stop when a warning
is encountered. If the WARN_AS_ERROR tag is set to FAIL_ON_WARNINGS then doxygen will continue
running as if WARN_AS_ERROR tag is set to NO, but at the end of the doxygen process doxygen will return
with a non-zero status. If the WARN_AS_ERROR tag is set to FAIL_ON_WARNINGS_PRINT then doxygen
behaves like FAIL_ON_WARNINGS but in case no WARN_LOGFILE is defined doxygen will not write the

128 Configuration
warning messages in between other messages but write them at the end of a run, in case a WARN_LOGFILE
is defined the warning messages will be besides being in the defined file also be shown at the end of a run,
unless the WARN_LOGFILE is defined as - i.e. standard output (stdout) in that case the behavior will
remain as with the setting FAIL_ON_WARNINGS.
Possible values are: NO, YES, FAIL_ON_WARNINGS and FAIL_ON_WARNINGS_PRINT.
WARN_FORMAT The WARN_FORMAT tag determines the format of the warning messages that doxygen can
produce. The string should contain the $file, $line, and $text tags, which will be replaced by
the file and line number from which the warning originated and the warning text. Optionally the format
may contain $version, which will be replaced by the version of the file (if it could be obtained via
FILE_VERSION_FILTER)
See also
WARN_LINE_FORMAT
The default value is: $file:$line: $text.

WARN_LINE_FORMAT In the $text part of the WARN_FORMAT command it is possible that a reference to a
more specific place is given. To make it easier to jump to this place (outside of doxygen) the user can define
a custom ¨cut¨ / ¨paste¨ string.
Example:
WARN_LINE_FORMAT = "’vi $file +$line’"
See also
WARN_FORMAT
The default value is: at line $line of file $file.
WARN_LOGFILE The WARN_LOGFILE tag can be used to specify a file to which warning and error messages
should be written. If left blank the output is written to standard error (stderr). In case the file specified
cannot be opened for writing the warning and error messages are written to standard error. When as file - is
specified the warning and error messages are written to standard output (stdout).
23.5 Configuration options related to the input files
INPUT The INPUT tag is used to specify the files and/or directories that contain documented source files. You
may enter file names like myfile.cpp or directories like /usr/src/myproject. Separate the files or
directories with spaces. See also FILE_PATTERNS and EXTENSION_MAPPING
Note
If this tag is empty the current directory is searched.
INPUT_ENCODING This tag can be used to specify the character encoding of the source files that doxygen
parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses libiconv (or the iconv built into
libc) for the transcoding. See the libiconv documentation for the list of possible encodings.
See also
INPUT_FILE_ENCODING
The default value is: UTF-8.
INPUT_FILE_ENCODING This tag can be used to specify the character encoding of the source files that doxy-
gen parses The INPUT_FILE_ENCODING tag can be used to specify character encoding on a per file
pattern basis. Doxygen will compare the file name with each pattern and apply the encoding instead of
the default INPUT_ENCODING) if there is a match. The character encodings are a list of the form: pat-
tern=encoding (like ∗.php=ISO-8859-1).
See cfg_input_encoding ÏNPUT_ENCODING¨ for further information on supported encodings.

23.5 Configuration options related to the input files 129
FILE_PATTERNS If the value of the INPUT tag contains directories, you can use the FILE_PATTERNS tag to
specify one or more wildcard patterns (like ∗.cpp and ∗.h) to filter out the source-files in the directories.
Note that for custom extensions or not directly supported extensions you also need to set EXTENSION_MAPPING
for the extension otherwise the files are not read by doxygen.
Note the list of default checked file patterns might differ from the list of default file extension mappings.
If left blank the following patterns are tested: ∗.c, ∗.cc, ∗.cxx, ∗.cpp, ∗.c++, ∗.java, ∗.ii, ∗.ixx,
∗.ipp, ∗.i++, ∗.inl, ∗.idl, ∗.ddl, ∗.odl, ∗.h, ∗.hh, ∗.hxx, ∗.hpp, ∗.h++, ∗.l, ∗.cs, ∗.d,
∗.php, ∗.php4, ∗.php5, ∗.phtml, ∗.inc, ∗.m, ∗.markdown, ∗.md, ∗.mm, ∗.dox (to be provided
as doxygen C comment), ∗.py, ∗.pyw, ∗.f90, ∗.f95, ∗.f03, ∗.f08, ∗.f18, ∗.f, ∗.for, ∗.vhd,
∗.vhdl, ∗.ucf, ∗.qsf and ∗.ice.
RECURSIVE The RECURSIVE tag can be used to specify whether or not subdirectories should be searched for
input files as well.
EXCLUDE The EXCLUDE tag can be used to specify files and/or directories that should be excluded from the
INPUT source files. This way you can easily exclude a subdirectory from a directory tree whose root is
specified with the INPUT tag.
Note that relative paths are relative to the directory from which doxygen is run.
EXCLUDE_SYMLINKS The EXCLUDE_SYMLINKS tag can be used to select whether or not files or directories
that are symbolic links (a Unix file system feature) are excluded from the input.
EXCLUDE_PATTERNS If the value of the INPUT tag contains directories, you can use the EXCLUDE_←-
PATTERNS tag to specify one or more wildcard patterns to exclude certain files from those directories.
Note that the wildcards are matched against the file with absolute path, so to exclude all test directories for
example use the pattern ∗/test/∗
EXCLUDE_SYMBOLS The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names (names-
paces, classes, functions, etc.) that should be excluded from the output. The symbol name can be a fully
qualified name, a word, or if the wildcard ∗ is used, a substring. Examples: ANamespace, AClass,
ANamespace::AClass, ANamespace::∗Test
EXAMPLE_PATH The EXAMPLE_PATH tag can be used to specify one or more files or directories that contain
example code fragments that are included (see the \include command).
EXAMPLE_PATTERNS If the value of the EXAMPLE_PATH tag contains directories, you can use the EXAMPLE←-
_PATTERNS tag to specify one or more wildcard pattern (like ∗.cpp and ∗.h) to filter out the source-files
in the directories. If left blank all files are included.
EXAMPLE_RECURSIVE If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be searched for
input files to be used with the \include or \dontinclude commands irrespective of the value of the RECURSIVE
tag.
IMAGE_PATH The IMAGE_PATH tag can be used to specify one or more files or directories that contain images
that are to be included in the documentation (see the \image command).
INPUT_FILTER The INPUT_FILTER tag can be used to specify a program that doxygen should invoke to
filter for each input file. Doxygen will invoke the filter program by executing (via popen()) the command:
<filter> <input-file>
where <filter> is the value of the INPUT_FILTER tag, and <input-file> is the name of an input
file. Doxygen will then use the output that the filter program writes to standard output. If FILTER_PATTERNS
is specified, this tag will be ignored.
Note that the filter must not add or remove lines; it is applied before the code is scanned, but not when the
output code is generated. If lines are added or removed, the anchors will not be placed correctly.
Note that doxygen will use the data processed and written to standard output for further processing, therefore
nothing else, like debug statements or used commands (so in case of a Windows batch file always use
@echo OFF), should be written to standard output.

130 Configuration
for the extension otherwise the files are not properly processed by doxygen.
FILTER_PATTERNS The FILTER_PATTERNS tag can be used to specify filters on a per file pattern basis.
Doxygen will compare the file name with each pattern and apply the filter if there is a match. The filters are a
list of the form: pattern=filter (like ∗.cpp=my_cpp_filter). See INPUT_FILTER for further information
on how filters are used. If the FILTER_PATTERNS tag is empty or if none of the patterns match the file
name, INPUT_FILTER is applied.
for the extension otherwise the files are not properly processed by doxygen.
FILTER_SOURCE_FILES If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
INPUT_FILTER) will also be used to filter the input files that are used for producing the source files to browse
(i.e. when SOURCE_BROWSER is set to YES).
FILTER_SOURCE_PATTERNS The FILTER_SOURCE_PATTERNS tag can be used to specify source filters

per file pattern. A pattern will override the setting for FILTER_PATTERN (if any) and it is also possible to
disable source filtering for a specific pattern using ∗.ext= (so without naming a filter).
This tag requires that the tag FILTER_SOURCE_FILES is set to YES.
USE_MDFILE_AS_MAINPAGE If the USE_MDFILE_AS_MAINPAGE tag refers to the name of a markdown

file that is part of the input, its contents will be placed on the main page (index.html). This can be useful
if you have a project on for instance GitHub and want to reuse the introduction page also for the doxygen
output.
FORTRAN_COMMENT_AFTER The Fortran standard specifies that for fixed formatted Fortran code all characters
from position 72 are to be considered as comment. A common extension is to allow longer lines before the
automatic comment starts. The setting FORTRAN_COMMENT_AFTER will also make it possible that longer
lines can be processed before the automatic comment starts.
23.6 Configuration options related to source browsing
SOURCE_BROWSER If the SOURCE_BROWSER tag is set to YES then a list of source files will be generated.
Documented entities will be cross-referenced with these sources.
Note: To get rid of all source code in the generated output, make sure that also VERBATIM_HEADERS is set
to NO.
INLINE_SOURCES Setting the INLINE_SOURCES tag to YES will include the body of functions, classes and
enums directly into the documentation.
STRIP_CODE_COMMENTS Setting the STRIP_CODE_COMMENTS tag to YES will instruct doxygen to hide any
special comment blocks from generated source code fragments. Normal C, C++ and Fortran comments will
always remain visible.
REFERENCED_BY_RELATION If the REFERENCED_BY_RELATION tag is set to YES then for each docu-
mented entity all documented functions referencing it will be listed.
REFERENCES_RELATION If the REFERENCES_RELATION tag is set to YES then for each documented func-
tion all documented entities called/used by that function will be listed.

23.6 Configuration options related to source browsing 131
REFERENCES_LINK_SOURCE If the REFERENCES_LINK_SOURCE tag is set to YES and SOURCE_BROWSER

tag is set to YES then the hyperlinks from functions in REFERENCES_RELATION and REFERENCED_BY_RELATION
lists will link to the source code. Otherwise they will link to the documentation.
SOURCE_TOOLTIPS If SOURCE_TOOLTIPS is enabled (the default) then hovering a hyperlink in the source
code will show a tooltip with additional information such as prototype, brief description and links to the defini-
tion and documentation. Since this will make the HTML file larger and loading of large files a bit slower, you
can opt to disable this feature.
This tag requires that the tag SOURCE_BROWSER is set to YES.
USE_HTAGS If the USE_HTAGS tag is set to YES then the references to source code will point to the HTML gen-
erated by the htags(1) tool instead of doxygen built-in source browser. The htags tool is part of GNU's
global source tagging system (see https://www.gnu.org/software/global/global.html).
You will need version 4.8.6 or higher.
To use it do the following:
1. Install the latest version of global

2. Enable SOURCE_BROWSER and USE_HTAGS in the configuration file
3. Make sure the INPUT points to the root of the source tree
4. Run doxygen as normal
Doxygen will invoke htags (and that will in turn invoke gtags), so these tools must be available from
the command line (i.e. in the search path).
The result: instead of the source browser generated by doxygen, the links to source code will now point
to the output of htags.

This tag requires that the tag SOURCE_BROWSER is set to YES.
VERBATIM_HEADERS If the VERBATIM_HEADERS tag is set the YES then doxygen will generate a verbatim
copy of the header file for each class for which an include is specified. Set to NO to disable this.
See also
Section \class.
CLANG_ASSISTED_PARSING If the CLANG_ASSISTED_PARSING tag is set to YES then doxygen will use
the clang parser for more accurate parsing at the cost of reduced performance. This can be particularly
helpful with template rich C++ code for which doxygen's built-in parser lacks the necessary type information.
Note
The availability of this option depends on whether or not doxygen was generated with the -Duse_←-
libclang=ON option for CMake.
CLANG_ADD_INC_PATHS If the CLANG_ASSISTED_PARSING tag is set to YES and the CLANG_ADD_←-

INC_PATHS tag is set to YES then doxygen will add the directory of each input to the include path.
This tag requires that the tag CLANG_ASSISTED_PARSING is set to YES.
CLANG_OPTIONS If clang assisted parsing is enabled you can provide the compiler with command line options
that you would normally use when invoking the compiler. Note that the include paths will already be set by
doxygen for the files and directories specified with INPUT and INCLUDE_PATH.
This tag requires that the tag CLANG_ASSISTED_PARSING is set to YES.

132 Configuration
CLANG_DATABASE_PATH If clang assisted parsing is enabled you can provide the clang parser with the path
to the directory containing a file called compile_commands.json. This file is the compilation
database containing the options used when the source files were built. This is equivalent to specifying the
-p option to a clang tool, such as clang-check. These options will then be passed to the parser. Any
options specified with CLANG_OPTIONS will be added as well.
Note
libclang=ON option for CMake.
23.7 Configuration options related to the alphabetical class index
ALPHABETICAL_INDEX If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index of all com-
pounds will be generated. Enable this if the project contains a lot of classes, structs, unions or interfaces.
IGNORE_PREFIX The IGNORE_PREFIX tag can be used to specify a prefix (or a list of prefixes) that should
be ignored while generating the index headers. The IGNORE_PREFIX tag works for classes, function and
member names. The entity will be placed in the alphabetical list under the first letter of the entity name that
remains after removing the prefix.
This tag requires that the tag ALPHABETICAL_INDEX is set to YES.
23.8 Configuration options related to the HTML output
GENERATE_HTML If the GENERATE_HTML tag is set to YES, doxygen will generate HTML output
HTML_OUTPUT The HTML_OUTPUT tag is used to specify where the HTML docs will be put. If a relative path is
entered the value of OUTPUT_DIRECTORY will be put in front of it.
The default directory is: html.
This tag requires that the tag GENERATE_HTML is set to YES.
HTML_FILE_EXTENSION The HTML_FILE_EXTENSION tag can be used to specify the file extension for
each generated HTML page (for example: .htm, .php, .asp).
The default value is: .html.
HTML_HEADER The HTML_HEADER tag can be used to specify a user-defined HTML header file for each gen-
erated HTML page. If the tag is left blank doxygen will generate a standard header.
To get valid HTML the header file that includes any scripts and style sheets that doxygen needs, which is
dependent on the configuration options used (e.g. the setting GENERATE_TREEVIEW). It is highly recom-
mended to start with a default header using
doxygen -w html new_header.html new_footer.html new_stylesheet.css YourConfigFile
and then modify the file new_header.html.

See also section Doxygen usage for information on how to generate the default header that doxygen normally
uses.

23.8 Configuration options related to the HTML output 133
Note
The header is subject to change so you typically have to regenerate the default header when upgrading
to a newer version of doxygen. The following markers have a special meaning inside the header and
footer:
$title will be replaced with the title of the page.
$datetime will be replaced with the current date and time.
$date will be replaced with the current date.
$time will be replaced with the current time.
$year will be replaces with the current year.
$showdate(<format>) will be replaced with the current date and time according to the format
as specified by <format>. The <format> follows the rules as specified for the \showdate
command with the exception that no ) is allowed in the <format>.
$doxygenversion will be replaced with the version of doxygen
$projectname will be replaced with the name of the project (see PROJECT_NAME)
$projectnumber will be replaced with the project number (see PROJECT_NUMBER)
$projectbrief will be replaced with the project brief description (see PROJECT_BRIEF)
$projectlogo will be replaced with the project logo (see PROJECT_LOGO)
$generatedby will be replaced with the output language dependent version of the text ¨Generated
by¨ or when the TIMESTAMP is set by the output language dependent version of the text "Gener-
ated on $datetime for $projectname by".
$stylesheet will be replaced with the setting of HTML_STYLESHEET unless it is empty or the file
in which case it is replaced by the default setting doxygen.css.
$extrastylesheet will be replaced with the setting of HTML_EXTRA_STYLESHEET including
the required HTML tags for each extra stylesheet.
$treeview will be replaced with links to the javascript and style sheets needed for the navigation
tree (or an empty string when GENERATE_TREEVIEW is disabled).
$search will be replaced with a links to the javascript and style sheets needed for the search engine
(or an empty string when SEARCHENGINE is disabled).
$searchbox will be replaced with the HTML code needed for the search box to be shown (or an
empty string when SEARCHENGINE is disabled).
$mathjax will be replaced with a links to the javascript and style sheets needed for the MathJax
feature (or an empty string when USE_MATHJAX is disabled).
$relpath∧ If CREATE_SUBDIRS is enabled, the command $relpath∧ can be used to produce
a relative path to the root of the HTML output directory, e.g. use $relpath∧ doxygen.css, to
refer to the standard style sheet.
$navpath will be replaced with a path as required by GENERATE_TREEVIEW
To cope with differences in the layout of the header and footer that depend on configuration settings, the
header can also contain special blocks that will be copied to the output or skipped depending on the configu-
ration. Such blocks have the following form:

Some context copied when condition BLOCKNAME holds


Some context copied when condition BLOCKNAME does not hold

The following block names are supported:
DISABLE_INDEX Content within this block is copied to the output if the DISABLE_INDEX option is enabled
(so when the index is disabled).
GENERATE_TREEVIEW Content within this block is copied to the output if the GENERATE_TREEVIEW
option is enabled.
SEARCHENGINE Content within this block is copied to the output if the SEARCHENGINE option is enabled.
PROJECT_NAME Content within the block is copied to the output if the PROJECT_NAME option is not
empty.

134 Configuration
PROJECT_NUMBER Content within the block is copied to the output if the PROJECT_NUMBER option is
not empty.
PROJECT_BRIEF Content within the block is copied to the output if the PROJECT_BRIEF option is not
empty.
PROJECT_LOGO Content within the block is copied to the output if the PROJECT_LOGO option is not
empty.
FULL_SIDEBAR Content within the block is copied to the output if the FULL_SIDEBAR, DISABLE_INDEX
and GENERATE_TREEVIEW options are all enabled.
TITLEAREA Content within this block is copied to the output if a title is visible at the top of each page.
This is the case if either PROJECT_NAME, PROJECT_BRIEF, PROJECT_LOGO is filled in or if both
DISABLE_INDEX and SEARCHENGINE are enabled.
HTML_FOOTER The HTML_FOOTER tag can be used to specify a user-defined HTML footer for each generated
HTML page. If the tag is left blank doxygen will generate a standard footer.
See HTML_HEADER for more information on how to generate a default footer and what special commands
can be used inside the footer.
See also section Doxygen usage for information on how to generate the default footer that doxygen normally
uses.
HTML_STYLESHEET The HTML_STYLESHEET tag can be used to specify a user-defined cascading style sheet
that is used by each HTML page. It can be used to fine-tune the look of the HTML output. If left blank doxygen
will generate a default style sheet.
See also section Doxygen usage for information on how to generate the style sheet that doxygen normally
uses.
Note
It is recommended to use HTML_EXTRA_STYLESHEET instead of this tag, as it is more robust and

this tag (HTML_STYLESHEET) will in the future become obsolete.
HTML_EXTRA_STYLESHEET The HTML_EXTRA_STYLESHEET tag can be used to specify additional user-

defined cascading style sheets that are included after the standard style sheets created by doxygen. Using
this option one can overrule certain style aspects. This is preferred over using HTML_STYLESHEET since it
does not replace the standard style sheet and is therefore more robust against future updates. Doxygen will
copy the style sheet files to the output directory.
Note
The order of the extra style sheet files is of importance (e.g. the last style sheet in the list overrules the
setting of the previous ones in the list).
Since the styling of scrollbars can currently not be overruled in Webkit/Chromium, the styling will be
left out of the default doxygen.css if one or more extra stylesheets have been specified. So if scrollbar
customization is desired it has to be added explicitly. Here is an example style sheet that gives the
contents area a fixed width:
body {
background-color: #CCC;
color: black;
margin: 0;
}
div.contents {
margin-bottom: 10px;
padding: 12px;
margin-left: auto;
margin-right: auto;
width: 960px;

background-color: white;
border-radius: 8px;
}
#titlearea {
background-color: white;
}
hr.footer {
display: none;
}
.footer {
background-color: #AAA;
}
HTML_EXTRA_FILES The HTML_EXTRA_FILES tag can be used to specify one or more extra images or other
source files which should be copied to the HTML output directory. Note that these files will be copied to the
base HTML output directory. Use the $relpath∧ marker in the HTML_HEADER and/or HTML_FOOTER
files to load these files. In the HTML_STYLESHEET file, use the file name only. Also note that the files will
be copied as-is; there are no commands or markers available.
HTML_COLORSTYLE The HTML_COLORSTYLE tag can be used to specify if the generated HTML output should
be rendered with a dark or light theme.
Possible values are: LIGHT always generate light mode output, DARK always generate dark mode output,
AUTO_LIGHT automatically set the mode according to the user preference, use light mode if no preference
is set (the default), AUTO_DARK automatically set the mode according to the user preference, use dark mode
if no preference is set and TOGGLE allow to user to switch between light and dark mode via a button.
The default value is: AUTO_LIGHT.
HTML_COLORSTYLE_HUE The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. Doxygen
will adjust the colors in the style sheet and background images according to this color. Hue is specified as
an angle on a color-wheel, see https://en.wikipedia.org/wiki/Hue for more information. For
instance the value 0 represents red, 60 is yellow, 120 is green, 180 is cyan, 240 is blue, 300 purple, and 360
is red again.
HTML_COLORSTYLE_SAT The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of the colors
in the HTML output. For a value of 0 the output will use gray-scales only. A value of 255 will produce the most
vivid colors.
HTML_COLORSTYLE_GAMMA The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to

the luminance component of the colors in the HTML output. Values below 100 gradually make the output
lighter, whereas values above 100 make the output darker. The value divided by 100 is the actual gamma
applied, so 80 represents a gamma of 0.8, The value 220 represents a gamma of 2.2, and 100 does not
change the gamma.
HTML_DYNAMIC_MENUS If the HTML_DYNAMIC_MENUS tag is set to YES then the generated HTML docu-
mentation will contain a main index with vertical navigation menus that are dynamically created via Java←-
Script. If disabled, the navigation index will consists of multiple levels of tabs that are statically embedded
in every HTML page. Disable this option to support browsers that do not have JavaScript, like the Qt help
browser.

136 Configuration

HTML_DYNAMIC_SECTIONS If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML
documentation will contain sections that can be hidden and shown after the page has loaded.
HTML_INDEX_NUM_ENTRIES With HTML_INDEX_NUM_ENTRIES one can control the preferred number of

entries shown in the various tree structured indices initially; the user can expand and collapse entries dynam-
ically later on. Doxygen will expand the tree to such a level that at most the specified number of entries are
visible (unless a fully collapsed tree already exceeds this amount). So setting the number of entries 1 will
produce a full collapsed tree by default. 0 is a special value representing an infinite number of entries and will
result in a full expanded tree by default.
GENERATE_DOCSET If the GENERATE_DOCSET tag is set to YES, additional index files will be generated that
can be used as input for Apple's Xcode 3 integrated development environment,
introduced with OSX 10.5 (Leopard). To create a documentation set, doxygen will generate a
Makefile in the HTML output directory. Running make will produce the docset in that directory
and running make install will install the docset in ∼/Library/Developer/Shared/←-
Documentation/DocSets so that Xcode will find it at startup. See https://developer.←-
apple.com/library/archive/featuredarticles/DoxygenXcode/_index.html for
more information.
DOCSET_FEEDNAME This tag determines the name of the docset feed. A documentation feed provides an um-
brella under which multiple documentation sets from a single provider (such as a company or product suite)
can be grouped.
The default value is: Doxygen generated docs.
This tag requires that the tag GENERATE_DOCSET is set to YES.
DOCSET_FEEDURL This tag determines the URL of the docset feed. A documentation feed provides an umbrella
under which multiple documentation sets from a single provider (such as a company or product suite) can be
grouped.
DOCSET_BUNDLE_ID This tag specifies a string that should uniquely identify the documentation set bundle. This
should be a reverse domain-name style string, e.g. com.mycompany.MyDocSet. Doxygen will append
.docset to the name.
The default value is: org.doxygen.Project.
DOCSET_PUBLISHER_ID The DOCSET_PUBLISHER_ID tag specifies a string that should uniquely identify
the documentation publisher. This should be a reverse domain-name style string, e.g. com.mycompany.←-
MyDocSet.documentation.
The default value is: org.doxygen.Publisher.
DOCSET_PUBLISHER_NAME The DOCSET_PUBLISHER_NAME tag identifies the documentation publisher.

The default value is: Publisher.

GENERATE_HTMLHELP If the GENERATE_HTMLHELP tag is set to YES then doxygen generates three addi-
tional HTML index files: index.hhp, index.hhc, and index.hhk. The index.hhp is a project file
that can be read by Microsoft's HTML Help Workshop on Windows. In the beginning of 2021 Microsoft took the
original page, with a.o. the download links, offline the HTML help workshop was already many years in main-
tenance mode). You can download the HTML help workshop from the web archives at Installation
executable.
The HTML Help Workshop contains a compiler that can convert all HTML output generated by doxygen into
a single compiled HTML file (.chm). Compiled HTML files are now used as the Windows 98 help format,
and will replace the old Windows help format (.hlp) on all Windows platforms in the future. Compressed
HTML files also contain an index, a table of contents, and you can search for words in the documentation.
The HTML workshop also contains a viewer for compressed HTML files.
CHM_FILE The CHM_FILE tag can be used to specify the file name of the resulting .chm file. You can add a
path in front of the file if the result should not be written to the html output directory.
This tag requires that the tag GENERATE_HTMLHELP is set to YES.
HHC_LOCATION The HHC_LOCATION tag can be used to specify the location (absolute path including file
name) of the HTML help compiler (hhc.exe). If non-empty, doxygen will try to run the HTML help compiler
on the generated index.hhp.
The file has to be specified with full path.
GENERATE_CHI The GENERATE_CHI flag controls if a separate .chi index file is generated (YES) or that it
should be included in the main .chm file (NO).
CHM_INDEX_ENCODING The CHM_INDEX_ENCODING is used to encode HtmlHelp index (hhk), content

(hhc) and project file content.
BINARY_TOC The BINARY_TOC flag controls whether a binary table of contents is generated (YES) or a normal
table of contents (NO) in the .chm file. Furthermore it enables the Previous and Next buttons.
TOC_EXPAND The TOC_EXPAND flag can be set to YES to add extra items for group members to the table of
contents of the HTML help documentation and to the tree view.
SITEMAP_URL The SITEMAP_URL tag is used to specify the full URL of the place where the generated doc-
umentation will be placed on the server by the user during the deployment of the documentation. The gen-
erated sitemap is called sitemap.xml and placed on the directory specified by HTML_OUTPUT. In case
no SITEMAP_URL is specified no sitemap is generated. For information about the sitemap protocol see
https://www.sitemaps.org
GENERATE_QHP If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and QHP_VIRTUAL_FOLDER
are set, an additional index file will be generated that can be used as input for Qt's qhelpgenerator to generate
a Qt Compressed Help (.qch) of the generated HTML documentation.

138 Configuration
QCH_FILE If the QHG_LOCATION tag is specified, the QCH_FILE tag can be used to specify the file name of
the resulting .qch file. The path specified is relative to the HTML output folder.
This tag requires that the tag GENERATE_QHP is set to YES.
QHP_NAMESPACE The QHP_NAMESPACE tag specifies the namespace to use when generating Qt Help Project
output. For more information please see Qt Help Project / Namespace.
QHP_VIRTUAL_FOLDER The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating
Qt Help Project output. For more information please see Qt Help Project / Virtual Folders.
The default value is: doc.
QHP_CUST_FILTER_NAME If the QHP_CUST_FILTER_NAME tag is set, it specifies the name of a custom

filter to add. For more information please see Qt Help Project / Custom Filters.
QHP_CUST_FILTER_ATTRS The QHP_CUST_FILTER_ATTRS tag specifies the list of the attributes of the
custom filter to add. For more information please see Qt Help Project / Custom Filters.
QHP_SECT_FILTER_ATTRS The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this
project's filter section matches. Qt Help Project / Filter Attributes.
QHG_LOCATION The QHG_LOCATION tag can be used to specify the location (absolute path including file
name) of Qt's qhelpgenerator. If non-empty doxygen will try to run qhelpgenerator on the generated .qhp
file.
GENERATE_ECLIPSEHELP If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files will be
generated, together with the HTML files, they form an Eclipse help plugin.
To install this plugin and make it available under the help contents menu in Eclipse, the contents of the
directory containing the HTML and XML files needs to be copied into the plugins directory of eclipse. The
name of the directory within the plugins directory should be the same as the ECLIPSE_DOC_ID value.
After copying Eclipse needs to be restarted before the help appears.
ECLIPSE_DOC_ID A unique identifier for the Eclipse help plugin. When installing the plugin the directory
name containing the HTML and XML files should also have this name. Each documentation set should have
its own identifier.
This tag requires that the tag GENERATE_ECLIPSEHELP is set to YES.
DISABLE_INDEX If you want full control over the layout of the generated HTML pages it might be necessary
to disable the index and replace it with your own. The DISABLE_INDEX tag can be used to turn on/off
the condensed index (tabs) at top of each HTML page. A value of NO enables the index and the value YES
disables it. Since the tabs in the index contain the same information as the navigation tree, you can set this
option to YES if you also set GENERATE_TREEVIEW to YES.

GENERATE_TREEVIEW The GENERATE_TREEVIEW tag is used to specify whether a tree-like index structure
should be generated to display hierarchical information. If the tag value is set to YES, a side panel will be
generated containing a tree-like index structure (just like the one that is generated for HTML Help). For this
to work a browser that supports JavaScript, DHTML, CSS and frames is required (i.e. any modern browser).
Windows users are probably better off using the HTML help feature.
Via custom style sheets (see HTML_EXTRA_STYLESHEET) one can further fine tune the look of the index
(see Fine-tuning the output). As an example, the default style sheet generated by doxygen has an example
that shows how to put an image at the root of the tree instead of the PROJECT_NAME.
Since the tree basically has the same information as the tab index, you could consider setting
DISABLE_INDEX to YES when enabling this option.
FULL_SIDEBAR When both GENERATE_TREEVIEW and DISABLE_INDEX are set to YES, then the FULL←-
_SIDEBAR option determines if the side bar is limited to only the treeview area (value NO) or if it should
extend to the full height of the window (value YES). Setting this to YES gives a layout similar to https←-
://docs.readthedocs.io with more room for contents, but less room for the project logo, title, and
description.
If either GENERATE_TREEVIEW or DISABLE_INDEX is set to NO, this option has no effect.
ENUM_VALUES_PER_LINE The ENUM_VALUES_PER_LINE tag can be used to set the number of enum
values that doxygen will group on one line in the generated HTML documentation.
Note that a value of 0 will completely suppress the enum values from appearing in the overview section.
TREEVIEW_WIDTH If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be used to set the
initial width (in pixels) of the frame in which the tree is shown.
EXT_LINKS_IN_WINDOW If the EXT_LINKS_IN_WINDOW option is set to YES, doxygen will open links to
external symbols imported via tag files in a separate window.
OBFUSCATE_EMAILS If the OBFUSCATE_EMAILS tag is set to YES, doxygen will obfuscate email addresses.
HTML_FORMULA_FORMAT If the HTML_FORMULA_FORMAT option is set to svg, doxygen will use the
pdf2svg tool (see https://github.com/dawbarton/pdf2svg) or inkscape (see https←-
://inkscape.org) to generate formulas as SVG images instead of PNGs for the HTML output. These
images will generally look nicer at scaled resolutions.
Possible values are: png (the default) and svg (looks nicer but requires the pdf2svg or inkscape tool).
The default value is: png.
FORMULA_FONTSIZE Use this tag to change the font size of LATEX formulas included as images in the HTML
documentation. When you change the font size after a successful doxygen run you need to manually remove
any form_∗.png images from the HTML output directory to force them to be regenerated.

140 Configuration
FORMULA_MACROFILE The FORMULA_MACROFILE can contain LATEX \newcommand and \renewcommand

commands to create new LATEX commands to be used in formulas as building blocks. See the section
Including formulas for details.
USE_MATHJAX Enable the USE_MATHJAX option to render LATEX formulas using MathJax (see https←-
://www.mathjax.org) which uses client side JavaScript for the rendering instead of using pre-rendered
bitmaps. Use this if you do not have LATEX installed or if you want to formulas look prettier in the HTML out-
put. When enabled you may also need to install MathJax separately and configure the path to it using the
MATHJAX_RELPATH option.
MATHJAX_VERSION With MATHJAX_VERSION it is possible to specify the MathJax version to be used. Note
that the different versions of MathJax have different requirements with regards to the different settings, so it is
possible that also other MathJax settings have to be changed when switching between the different MathJax
versions.
Possible values are: MathJax_2 and MathJax_3.
The default value is: MathJax_2.
This tag requires that the tag USE_MATHJAX is set to YES.
MATHJAX_FORMAT When MathJax is enabled you can set the default output format to be used for the MathJax
output. For more details about the output format see MathJax version 2 and MathJax version
3.
Possible values are: HTML-CSS (which is slower, but has the best compatibility. This is the name for Math-
jax version 2, for MathJax version 3 this will be translated into chtml), NativeMML (i.e. MathML. Only
supported for NathJax 2. For MathJax version 3 chtml will be used instead.), chtml (This is the name for
Mathjax version 3, for MathJax version 2 this will be translated into HTML-CSS) and SVG.
The default value is: HTML-CSS.
MATHJAX_RELPATH When MathJax is enabled you need to specify the location relative to the HTML output
directory using the MATHJAX_RELPATH option. The destination directory should contain the MathJax.js
script. For instance, if the mathjax directory is located at the same level as the HTML output directory, then
MATHJAX_RELPATH should be ../mathjax. The default value points to the MathJax Content Delivery
Network so you can quickly see the result without installing MathJax. However, it is strongly recommended to
install a local copy of MathJax from https://www.mathjax.org before deployment.
The default value is:
• in case of MathJax version 2: https://cdn.jsdelivr.net/npm/mathjax@2

• in case of MathJax version 3: https://cdn.jsdelivr.net/npm/mathjax@3
MATHJAX_EXTENSIONS The MATHJAX_EXTENSIONS tag can be used to specify one or more MathJax
extension names that should be enabled during MathJax rendering. For example for MathJax version 2 (see
https://docs.mathjax.org/en/v2.7-latest/tex.html#tex-and-latex-extensions)←-
:
MATHJAX_EXTENSIONS = TeX/AMSmath TeX/AMSsymbols
For example for MathJax version 3 (see http://docs.mathjax.org/en/latest/input/tex/extensions/in

html):
MATHJAX_EXTENSIONS = ams
MATHJAX_CODEFILE The MATHJAX_CODEFILE tag can be used to specify a file with javascript pieces of
code that will be used on startup of the MathJax code. See the MathJax site for more details. As an
example to disable the ¨Math Renderer¨ menu item in the ¨Math Settings¨ menu of MathJax:

MATHJAX_CODEFILE = disableRenderer.js
with in the file disableRenderer.js:

MathJax.Hub.Config({
menuSettings: {
showRenderer: false,
}
});
SEARCHENGINE When the SEARCHENGINE tag is enabled doxygen will generate a search box for the HTML
output. The underlying search engine uses javascript and DHTML and should work on any modern
browser. Note that when using HTML help (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or doc-
sets (GENERATE_DOCSET) there is already a search function so this one should typically be disabled. For
large projects the javascript based search engine can be slow, then enabling SERVER_BASED_SEARCH
may provide a better solution.
It is possible to search using the keyboard; to jump to the search box use <access key> + S (what the
<access key> is depends on the OS and browser, but it is typically <CTRL>, <ALT>/<option>, or
both). Inside the search box use the <cursor down key> to jump into the search results window, the
results can be navigated using the <cursor keys>. Press <Enter> to select an item or <escape>
to cancel the search. The filter options can be selected when the cursor is inside the search box by pressing
<Shift>+<cursor down>. Also here use the <cursor keys> to select a filter and <Enter> or
<escape> to activate or cancel the filter option.
SERVER_BASED_SEARCH When the SERVER_BASED_SEARCH tag is enabled the search engine will be im-
plemented using a web server instead of a web client using JavaScript.
There are two flavors of web server based searching depending on the EXTERNAL_SEARCH setting. When
disabled, doxygen will generate a PHP script for searching and an index file used by the script. When
EXTERNAL_SEARCH is enabled the indexing and searching needs to be provided by external tools. See the
section External Indexing and Searching for details.
This tag requires that the tag SEARCHENGINE is set to YES.
EXTERNAL_SEARCH When EXTERNAL_SEARCH tag is enabled doxygen will no longer generate the PHP script
for searching. Instead the search results are written to an XML file which needs to be processed by an external
indexer. Doxygen will invoke an external search engine pointed to by the SEARCHENGINE_URL option to
obtain the search results.
Doxygen ships with an example indexer (doxyindexer) and search engine (doxysearch.cgi) which
are based on the open source search engine library Xapian.
See the section External Indexing and Searching for details.
SEARCHENGINE_URL The SEARCHENGINE_URL should point to a search engine hosted by a web server
which will return the search results when EXTERNAL_SEARCH is enabled.
Doxygen ships with an example indexer (doxyindexer) and search engine (doxysearch.←-
cgi) which are based on the open source search engine library Xapian. See the section
External Indexing and Searching for details.
SEARCHDATA_FILE When SERVER_BASED_SEARCH and EXTERNAL_SEARCH are both enabled the unin-
dexed search data is written to a file for indexing by an external tool. With the SEARCHDATA_FILE tag the
name of this file can be specified.
The default file is: searchdata.xml.

142 Configuration
EXTERNAL_SEARCH_ID When SERVER_BASED_SEARCH and EXTERNAL_SEARCH are both enabled the

EXTERNAL_SEARCH_ID tag can be used as an identifier for the project. This is useful in combination with
EXTRA_SEARCH_MAPPINGS to search through multiple projects and redirect the results back to the right
project.
EXTRA_SEARCH_MAPPINGS The EXTRA_SEARCH_MAPPINGS tag can be used to enable searching through

doxygen projects other than the one defined by this configuration file, but that are all added to the same
external search index. Each project needs to have a unique id set via EXTERNAL_SEARCH_ID. The search
mapping then maps the id of to a relative location where the documentation can be found.
The format is:
EXTRA_SEARCH_MAPPINGS = tagname1=loc1 tagname2=loc2 ...
23.9 Configuration options related to the LaTeX output
GENERATE_LATEX If the GENERATE_LATEX tag is set to YES, doxygen will generate LATEX output.
LATEX_OUTPUT The LATEX_OUTPUT tag is used to specify where the LATEX docs will be put. If a relative path
is entered the value of OUTPUT_DIRECTORY will be put in front of it.
The default directory is: latex.
This tag requires that the tag GENERATE_LATEX is set to YES.
LATEX_CMD_NAME The LATEX_CMD_NAME tag can be used to specify the LATEX command name to be in-
voked.
Note that when not enabling USE_PDFLATEX the default is latex when enabling USE_PDFLATEX the
default is pdflatex and when in the later case latex is chosen this is overwritten by pdflatex. For
specific output languages the default can have been set differently, this depends on the implementation of the
output language.
MAKEINDEX_CMD_NAME The MAKEINDEX_CMD_NAME tag can be used to specify the command name to
generate index for LATEX.
Note
This tag is used in the Makefile / make.bat.
See also
LATEX_MAKEINDEX_CMD for the part in the generated output file (.tex).
The default file is: makeindex.

LATEX_MAKEINDEX_CMD The LATEX_MAKEINDEX_CMD tag can be used to specify the command name to
generate index for LATEX. In case there is no backslash (\) as first character it will be automatically added in
the LATEX code.
Note
This tag is used in the generated output file (.tex).

23.9 Configuration options related to the LaTeX output 143
See also
MAKEINDEX_CMD_NAME for the part in the Makefile / make.bat.
The default value is: makeindex.

COMPACT_LATEX If the COMPACT_LATEX tag is set to YES, doxygen generates more compact LATEX docu-
ments. This may be useful for small projects and may help to save some trees in general.
PAPER_TYPE The PAPER_TYPE tag can be used to set the paper type that is used by the printer.
Possible values are: a4 (210 x 297 mm), letter (8.5 x 11 inches), legal (8.5 x 14 inches) and
executive (7.25 x 10.5 inches).
The default value is: a4.
EXTRA_PACKAGES The EXTRA_PACKAGES tag can be used to specify one or more LATEX package names that
should be included in the LATEX output. The package can be specified just by its name or with the correct
syntax as to be used with the LATEX \usepackage command.
To get the times font for instance you can specify :
EXTRA_PACKAGES=times
or
EXTRA_PACKAGES={times}
To use the option intlimits with the amsmath package you can specify:
EXTRA_PACKAGES=[intlimits]{amsmath}
If left blank no extra packages will be included.

LATEX_HEADER The LATEX_HEADER tag can be used to specify a user-defined LATEX header for the generated
LATEX document. The header should contain everything until the first chapter. If it is left blank doxygen will
generate a standard header.
It is highly recommended to start with a default header using
doxygen -w latex new_header.tex new_footer.tex new_stylesheet.sty
and then modify the file new_header.tex.

See also section Doxygen usage for information on how to generate the default header that doxygen normally
uses.
Note: Only use a user-defined header if you know what you are doing!
Note
The header is subject to change so you typically have to regenerate the default header when upgrading
to a newer version of doxygen. The following commands have a special meaning inside the header (and
footer):
$title will be replaced with the project name.
$datetime will be replaced with the current date and time.
$date will be replaced with the current date.
$time will be replaced with the current time.
$year will be replaces with the current year.
$showdate(<format>) will be replaced with the current date and time according to the format
as specified by <format>. The <format> follows the rules as specified for the \showdate
command with the exception that no ) is allowed in the <format>.

144 Configuration
$doxygenversion will be replaced with the version of doxygen

$projectname will be replaced with the name of the project (see PROJECT_NAME)
$projectnumber will be replaced with the project number (see PROJECT_NUMBER)
$projectbrief will be replaced with the project brief description (see PROJECT_BRIEF)
$projectlogo will be replaced with the project logo (see PROJECT_LOGO)
$latexdocumentpre will be replaced by an output language dependent setting e.g. embed the
entire document in a special environment (for Chinese, Japanese etc.) Commonly used together
with $latexdocumentpost in the footer.
$latexdocumentpost will be replaced by an output language dependent setting e.g. embed the
entire document in a special environment (for Chinese, Japanese etc.) Commonly used together
with $latexdocumentpre in the header.
$generatedby will be replaced with the output language dependent version of the text ¨Generated
by¨ or when the TIMESTAMP is set by the output language dependent version of the text "Gener-
ated on $datetime for $projectname by".
$latexcitereference will be replaced by the output language dependent$ version of the word
¨Bibliography¨. This setting is typically used in combination with the block name CITATIONS_←-
PRESENT.
$latexbibstyle will be replaced with the latex bib style to be used as set by LATEX_BIB_STYLE,
in case nothing is set the bib style plain is used. This setting is typically used in combination
with the block name CITATIONS_PRESENT.
$latexbibfiles will be replaced by the comma separated list of bib. files as set by
CITE_BIB_FILES (when necessary a missing .bib is automatically added). This setting is
typically used in combination with the block name CITATIONS_PRESENT.
$papertype will be replaced by the paper type as set in PAPER_TYPE and the word ¨paper¨ is
directly appended to it to have a correct LATEX paper type.
$langISO will be replaced by the ISO language name.
$languagesupport will be replaced by an output language dependent setting of packages re-
quired for translating terms of the specified language.
$latexfontenc will be replaced by an output language dependent setting of the fontencoding to
be used. This setting is typically used in combination with the block name LATEX_FONTENC.
$latexfont will be replaced by an output language dependent setting of the fonts to be used.
$latexemojidirectory will be replaced by the directory as set in LATEX_EMOJI_DIRECTORY
with the backslashes replaced by forward slashes (so usable by LATEX). In case the
LATEX_EMOJI_DIRECTORY is empty, the current directory will be used.
$makeindex will be replaced by the command as set in LATEX_MAKEINDEX_CMD. Then the com-
mand doesn't start with a backslash, a backslash is automatically prepended. In case the setting
is empty the command \makeindex is used.
$extralatexpackages will be replaced by commands for using the packages set in
EXTRA_PACKAGES.
$extralatexstylesheet will be replaced by commands for using the packages set in
LATEX_EXTRA_STYLESHEET (when the extension is the default extension, .sty, this extension
is stripped for the package name).
$latexspecialformulachars will be replaced by the code for some special unicode characters
that are commonly used (i.e. superscript minus, superscript 2 and superscript 3)
$formulamacrofile will be replaced by the name of the file as set in FORMULA_MACROFILE.
This setting is typically used in combination with the block name FORMULA_MACROFILE.
To cope with differences in the layout of the header and footer that depend on configuration settings, the
header and footer can also contain special blocks that will be copied to the output or skipped depending on
the configuration. Such blocks have the following form:
%%BEGIN BLOCKNAME
Some context copied when condition BLOCKNAME holds
%%END BLOCKNAME
%%BEGIN !BLOCKNAME
Some context copied when condition BLOCKNAME does not hold
%%END !BLOCKNAME

23.9 Configuration options related to the LaTeX output 145
The following block names are set based on the used settings in the configuration file:
COMPACT_LATEX Content within this block is copied to the output when the COMPACT_LATEX option is
enabled.
PDF_HYPERLINKS Content within this block is copied to the output when the PDF_HYPERLINKS option
is enabled.
USE_PDFLATEX Content within this block is copied to the output when the USE_PDFLATEX option is en-
abled.
LATEX_BATCHMODE Content within this block is copied to the output when the LATEX_BATCHMODE op-
tion is enabled.
TIMESTAMP Content within this block is copied to the output when the TIMESTAMP option is enabled.
The following block names are set based on the fact whether or not the tag has a value in the used configu-
ration file:
LATEX_FONTENC Content within this block is copied to the output when the doxygen latex translator func-
tion returns a value for the font encoding to be used. It is to be used in combination with the above
mentioned $latexfontenc.
FORMULA_MACROFILE Content within this block is copied to the output when the FORMULA_MACROFILE
option is not empty. It is to be used in combination with the above mentioned $formulamacrofile.
The following block name is set based on whether or not a feature is used in the documentation:
CITATIONS_PRESENT Content within this block is copied to the output when in the documentation ci-
tations are present and the relevant .. are present. It is to be used in combination with the above
mentioned $latexcitereference, $latexbibstyle and $latexbibfiles.
LATEX_FOOTER The LATEX_FOOTER tag can be used to specify a user-defined LATEX footer for the generated
LATEX document. The footer should contain everything after the last chapter. If it is left blank doxygen will
generate a standard footer.
See LATEX_HEADER for more information on how to generate a default footer and what special commands
can be used inside the footer.
See also section Doxygen usage for information on how to generate the default footer that doxygen normally
uses.
Note: Only use a user-defined footer if you know what you are doing!
LATEX_EXTRA_STYLESHEET The LATEX_EXTRA_STYLESHEET tag can be used to specify additional

user-defined LATEX style sheets that are included after the standard style sheets created by doxygen. Us-
ing this option one can overrule certain style aspects. Doxygen will copy the style sheet files to the output
directory.
Note
The order of the extra style sheet files is of importance (e.g. the last style sheet in the list overrules the
setting of the previous ones in the list).
LATEX_EXTRA_FILES The LATEX_EXTRA_FILES tag can be used to specify one or more extra images or
other source files which should be copied to the LATEX_OUTPUT output directory. Note that the files will be
copied as-is; there are no commands or markers available.
PDF_HYPERLINKS If the PDF_HYPERLINKS tag is set to YES, the LATEX that is generated is prepared for
conversion to PDF (using ps2pdf or pdflatex). The PDF file will contain links (just like the HTML output)
instead of page references. This makes the output suitable for online browsing using a PDF viewer.

146 Configuration
USE_PDFLATEX If the USE_PDFLATEX tag is set to YES, doxygen will use the engine as specified with
LATEX_CMD_NAME to generate the PDF file directly from the LATEX files. Set this option to YES, to get
a higher quality PDF documentation.
See also section LATEX_CMD_NAME for selecting the engine.
LATEX_BATCHMODE The LATEX_BATCHMODE tag ignals the behavior of LATEX in case of an error.
Possible values are: NO same as ERROR_STOP, YES same as BATCH, BATCH In batch mode nothing is
printed on the terminal, errors are scrolled as if <return> is hit at every error; missing files that TeX tries
to input or request from keyboard input (\read on a not open input stream) cause the job to abort, NON_←-
STOP In nonstop mode the diagnostic message will appear on the terminal, but there is no possibility of user
interaction just like in batch mode, SCROLL In scroll mode, TeX will stop only for missing files to input or if
keyboard input is necessary and ERROR_STOP In errorstop mode, TeX will stop at each error, asking for
user intervention.
LATEX_HIDE_INDICES If the LATEX_HIDE_INDICES tag is set to YES then doxygen will not include the
index chapters (such as File Index, Compound Index, etc.) in the output.
LATEX_BIB_STYLE The LATEX_BIB_STYLE tag can be used to specify the style to use for the bibliography,
e.g. plainnat, or ieeetr. See https://en.wikipedia.org/wiki/BibTeX and \cite for
more info.
The default value is: plain.
LATEX_EMOJI_DIRECTORY The LATEX_EMOJI_DIRECTORY tag is used to specify the (relative or abso-

lute) path from which the emoji images will be read. If a relative path is entered, it will be relative to the
LATEX_OUTPUT directory. If left blank the LATEX_OUTPUT directory will be used.
23.10 Configuration options related to the RTF output
GENERATE_RTF If the GENERATE_RTF tag is set to YES, doxygen will generate RTF output. The RTF output
is optimized for Word 97 and may not look too pretty with other RTF readers/editors.
RTF_OUTPUT The RTF_OUTPUT tag is used to specify where the RTF docs will be put. If a relative path is
The default directory is: rtf.
This tag requires that the tag GENERATE_RTF is set to YES.
COMPACT_RTF If the COMPACT_RTF tag is set to YES, doxygen generates more compact RTF documents. This
may be useful for small projects and may help to save some trees in general.
RTF_HYPERLINKS If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated will contain hyperlink
fields. The RTF file will contain links (just like the HTML output) instead of page references. This makes the
output suitable for online browsing using Word or some other Word compatible readers that support those
fields.

23.11 Configuration options related to the man page output 147
Note: WordPad (write) and others do not support links.

RTF_STYLESHEET_FILE Load stylesheet definitions from file. Syntax is similar to doxygen's configuration file,
i.e. a series of assignments. You only have to provide replacements, missing definitions are set to their default
value.
See also section Doxygen usage for information on how to generate the default style sheet that doxygen
normally uses.
RTF_EXTENSIONS_FILE Set optional variables used in the generation of an RTF document. Syntax is simi-
lar to doxygen's configuration file. A template extensions file can be generated using doxygen -e rtf
extensionFile.
23.11 Configuration options related to the man page output
GENERATE_MAN If the GENERATE_MAN tag is set to YES, doxygen will generate man pages for classes and
files.
MAN_OUTPUT The MAN_OUTPUT tag is used to specify where the man pages will be put. If a relative path is
entered the value of OUTPUT_DIRECTORY will be put in front of it. A directory man3 will be created inside
the directory specified by MAN_OUTPUT.
The default directory is: man.
This tag requires that the tag GENERATE_MAN is set to YES.
MAN_EXTENSION The MAN_EXTENSION tag determines the extension that is added to the generated man
pages. In case the manual section does not start with a number, the number 3 is prepended. The dot (.) at
the beginning of the MAN_EXTENSION tag is optional.
The default value is: .3.
MAN_SUBDIR The MAN_SUBDIR tag determines the name of the directory created within MAN_OUTPUT in
which the man pages are placed. If defaults to man followed by MAN_EXTENSION with the initial . removed.
MAN_LINKS If the MAN_LINKS tag is set to YES and doxygen generates man output, then it will generate one
additional man file for each entity documented in the real man page(s). These additional files only source the
real man page, but without them the man command would be unable to find the correct page.
23.12 Configuration options related to the XML output
GENERATE_XML If the GENERATE_XML tag is set to YES, doxygen will generate an XML file that captures the
structure of the code including all documentation.

148 Configuration
XML_OUTPUT The XML_OUTPUT tag is used to specify where the XML pages will be put. If a relative path is
The default directory is: xml.
This tag requires that the tag GENERATE_XML is set to YES.
XML_PROGRAMLISTING If the XML_PROGRAMLISTING tag is set to YES, doxygen will dump the program
listings (including syntax highlighting and cross-referencing information) to the XML output. Note that enabling
this will significantly increase the size of the XML output.
XML_NS_MEMB_FILE_SCOPE If the XML_NS_MEMB_FILE_SCOPE tag is set to YES, doxygen will include

namespace members in file scope as well, matching the HTML output.
23.13 Configuration options related to the DOCBOOK output
GENERATE_DOCBOOK If the GENERATE_DOCBOOK tag is set to YES, doxygen will generate Docbook files that
can be used to generate PDF.
DOCBOOK_OUTPUT The DOCBOOK_OUTPUT tag is used to specify where the Docbook pages will be put. If a
relative path is entered the value of OUTPUT_DIRECTORY will be put in front of it.
The default directory is: docbook.
This tag requires that the tag GENERATE_DOCBOOK is set to YES.
23.14 Configuration options for the AutoGen Definitions output
GENERATE_AUTOGEN_DEF If the GENERATE_AUTOGEN_DEF tag is set to YES, doxygen will generate an

AutoGen Definitions (see https://autogen.sourceforge.net/) file that captures the structure
of the code including all documentation. Note that this feature is still experimental and incomplete at the
moment.
23.15 Configuration options related to Sqlite3 output
GENERATE_SQLITE3 If the GENERATE_SQLITE3 tag is set to YES doxygen will generate a Sqlite3
database with symbols found by doxygen stored in tables.
Note
sqlite3=ON option for CMake.
SQLITE3_OUTPUT The SQLITE3_OUTPUT tag is used to specify where the Sqlite3 database will be put.
If a relative path is entered the value of OUTPUT_DIRECTORY will be put in front of it.

23.16 Configuration options related to the Perl module output 149
Note
The default directory is: sqlite3.

This tag requires that the tag GENERATE_SQLITE3 is set to YES.
SQLITE3_RECREATE_DB The SQLITE3_OVERWRITE_DB tag is set to YES, the existing doxygen_sqlite3.db

database file will be recreated with each doxygen run. If set to NO, doxygen will warn if an a database file is
already found and not modify it.
Note

This tag requires that the tag GENERATE_SQLITE3 is set to YES.
23.16 Configuration options related to the Perl module output
GENERATE_PERLMOD If the GENERATE_PERLMOD tag is set to YES, doxygen will generate a Perl module file
that captures the structure of the code including all documentation.
Note that this feature is still experimental and incomplete at the moment.
PERLMOD_LATEX If the PERLMOD_LATEX tag is set to YES, doxygen will generate the necessary Makefile
rules, Perl scripts and LATEX code to be able to generate PDF and DVI output from the Perl module output.
This tag requires that the tag GENERATE_PERLMOD is set to YES.
PERLMOD_PRETTY If the PERLMOD_PRETTY tag is set to YES, the Perl module output will be nicely formatted
so it can be parsed by a human reader. This is useful if you want to understand what is going on. On the
other hand, if this tag is set to NO, the size of the Perl module output will be much smaller and Perl will parse
it just the same.
PERLMOD_MAKEVAR_PREFIX The names of the make variables in the generated doxyrules.make file
are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX. This is useful so different
doxyrules.make files included by the same Makefile don't overwrite each other's variables.
23.17 Configuration options related to the preprocessor
ENABLE_PREPROCESSING If the ENABLE_PREPROCESSING tag is set to YES, doxygen will evaluate all
C-preprocessor directives found in the sources and include files.
MACRO_EXPANSION If the MACRO_EXPANSION tag is set to YES, doxygen will expand all macro names in the
source code. If set to NO, only conditional compilation will be performed. Macro expansion can be done in a
controlled way by setting EXPAND_ONLY_PREDEF to YES.
This tag requires that the tag ENABLE_PREPROCESSING is set to YES.

150 Configuration
EXPAND_ONLY_PREDEF If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set

to YES then the macro expansion is limited to the macros specified with the PREDEFINED and
EXPAND_AS_DEFINED tags.
SEARCH_INCLUDES If the SEARCH_INCLUDES tag is set to YES, the include files in the INCLUDE_PATH will
be searched if a #include is found.
INCLUDE_PATH The INCLUDE_PATH tag can be used to specify one or more directories that contain include
files that are not input files but should be processed by the preprocessor.
Note that the INCLUDE_PATH is not recursive, so the setting of RECURSIVE has no effect here.
This tag requires that the tag SEARCH_INCLUDES is set to YES.
INCLUDE_FILE_PATTERNS You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wild-
card patterns (like ∗.h and ∗.hpp) to filter out the header-files in the directories. If left blank, the patterns
specified with FILE_PATTERNS will be used.
PREDEFINED The PREDEFINED tag can be used to specify one or more macro names that are defined before
the preprocessor is started (similar to the -D option of e.g. gcc). The argument of the tag is a list of macros
of the form: name or name=definition (no spaces). If the definition and the ¨=¨ are omitted, ¨=1¨ is
assumed. To prevent a macro definition from being undefined via #undef or recursively expanded use the
:= operator instead of the = operator.
EXPAND_AS_DEFINED If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then
this tag can be used to specify a list of macro names that should be expanded. The macro definition that is
found in the sources will be used. Use the PREDEFINED tag if you want to use a different macro definition
that overrules the definition found in the source code.
SKIP_FUNCTION_MACROS If the SKIP_FUNCTION_MACROS tag is set to YES then doxygen's preprocessor

will remove all references to function-like macros that are alone on a line, have an all uppercase name, and
do not end with a semicolon. Such function macros are typically used for boiler-plate code, and will confuse
the parser if not removed.
23.18 Configuration options related to external references
TAGFILES The TAGFILES tag can be used to specify one or more tag files.
For each tag file the location of the external documentation should be added. The format of a tag file without
this location is as follows:
TAGFILES = file1 file2 ...
Adding location for the tag files is done as follows:
TAGFILES = file1=loc1 "file2 = loc2" ...
where loc1 and loc2 can be relative or absolute paths or URLs. See the section Linking to external documentation
for more information about the use of tag files.

23.19 Configuration options related to diagram generator tools 151
Note
Each tag file must have a unique name (where the name does NOT include the path). If a tag file is not
located in the directory in which doxygen is run, you must also specify the path to the tagfile here.
GENERATE_TAGFILE When a file name is specified after GENERATE_TAGFILE, doxygen will create a tag file
that is based on the input files it reads. See section Linking to external documentation for more information
about the usage of tag files.
ALLEXTERNALS If the ALLEXTERNALS tag is set to YES, all external class will be listed in the class index. If
set to NO, only the inherited external classes will be listed.
EXTERNAL_GROUPS If the EXTERNAL_GROUPS tag is set to YES, all external groups will be listed in the
modules index. If set to NO, only the current project's groups will be listed.
EXTERNAL_PAGES If the EXTERNAL_PAGES tag is set to YES, all external pages will be listed in the related
pages index. If set to NO, only the current project's pages will be listed.
23.19 Configuration options related to diagram generator tools
HIDE_UNDOC_RELATIONS If set to YES the inheritance and collaboration graphs will hide inheritance and
usage relations if the target is undocumented or is not a class.
HAVE_DOT If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is available from the
path. This tool is part of Graphviz, a graph visualization toolkit from AT&T and Lucent Bell Labs. The
other options in this section have no effect if this option is set to NO
DOT_NUM_THREADS The DOT_NUM_THREADS specifies the number of dot invocations doxygen is allowed to
run in parallel. When set to 0 doxygen will base this on the number of processors available in the system. You
can set it explicitly to a value larger than 0 to get control over the balance between CPU load and processing
speed.
This tag requires that the tag HAVE_DOT is set to YES.
DOT_COMMON_ATTR DOT_COMMON_ATTR is common attributes for nodes, edges and labels of subgraphs.
When you want a differently looking font in the dot files that doxygen generates you can specify fontname,
fontcolor and fontsize attributes. For details please see Node, Edge and Graph Attributes
specification You need to make sure dot is able to find the font, which can be done by putting it in
a standard location or by setting the DOTFONTPATH environment variable or by setting DOT_FONTPATH to
the directory containing the font. Default graphviz fontsize is 14.
The default value is: fontname=Helvetica,fontsize=10.
DOT_EDGE_ATTR DOT_EDGE_ATTR is concatenated with DOT_COMMON_ATTR. For elegant style you

can add 'arrowhead=open, arrowtail=open, arrowsize=0.5'. Complete documentation about
arrows shapes.
The default value is: labelfontname=Helvetica,labelfontsize=10.

152 Configuration
DOT_NODE_ATTR DOT_NODE_ATTR is concatenated with DOT_COMMON_ATTR. For view without boxes

around nodes set 'shape=plain' or 'shape=plaintext' Shapes specification
The default value is: shape=box,height=0.2,width=0.4.
DOT_FONTPATH You can set the path where dot can find font specified with fontname in DOT_COMMON_ATTR
and others dot attributes.
CLASS_GRAPH If the CLASS_GRAPH tag is set to YES or GRAPH or BUILTIN then doxygen will generate a
graph for each documented class showing the direct and indirect inheritance relations. In case the CLASS←-
_GRAPH tag is set to YES or GRAPH and HAVE_DOT is enabled as well, then dot will be used to draw the
graph. In case the CLASS_GRAPH tag is set to YES and HAVE_DOT is disabled or if the CLASS_GRAPH
tag is set to BUILTIN, then the built-in generator will be used. If the CLASS_GRAPH tag is set to TEXT the
direct and indirect inheritance relations will be shown as texts / links.
Possible values are: NO, YES, TEXT, GRAPH and BUILTIN.
COLLABORATION_GRAPH If the COLLABORATION_GRAPH tag is set to YES then doxygen will generate a
graph for each documented class showing the direct and indirect implementation dependencies (inheritance,
containment, and class references variables) of the class with other documented classes.
GROUP_GRAPHS If the GROUP_GRAPHS tag is set to YES then doxygen will generate a graph for groups, show-
ing the direct groups dependencies.
See also the chapter Grouping in the manual.
UML_LOOK If the UML_LOOK tag is set to YES, doxygen will generate inheritance and collaboration diagrams in
a style similar to the OMG's Unified Modeling Language.
UML_LIMIT_NUM_FIELDS If the UML_LOOK tag is enabled, the fields and methods are shown inside the
class node. If there are many fields or methods and many nodes the graph may become too big to be useful.
The UML_LIMIT_NUM_FIELDS threshold limits the number of items for each type to make the size more
manageable. Set this to 0 for no limit. Note that the threshold may be exceeded by 50% before the limit is
enforced. So when you set the threshold to 10, up to 15 fields may appear, but if the number exceeds 15, the
total amount of fields shown is limited to 10.
This tag requires that the tag UML_LOOK is set to YES.
DOT_UML_DETAILS If the DOT_UML_DETAILS tag is set to NO, doxygen will show attributes and methods
without types and arguments in the UML graphs. If the DOT_UML_DETAILS tag is set to YES, doxygen will
add type and arguments for attributes and methods in the UML graphs. If the DOT_UML_DETAILS tag is
set to NONE, doxygen will not generate fields with class member information in the UML graphs. The class
diagrams will look similar to the default class diagrams but using UML notation for the relationships.
Possible values are: NO, YES and NONE.
This tag requires that the tag UML_LOOK is set to YES.

23.19 Configuration options related to diagram generator tools 153
DOT_WRAP_THRESHOLD The DOT_WRAP_THRESHOLD tag can be used to set the maximum number of char-
acters to display on a single line. If the actual line length exceeds this threshold significantly it will wrapped
across multiple lines. Some heuristics are apply to avoid ugly line breaks.
TEMPLATE_RELATIONS If the TEMPLATE_RELATIONS tag is set to YES then the inheritance and collabora-
tion graphs will show the relations between templates and their instances.
INCLUDE_GRAPH If the INCLUDE_GRAPH, ENABLE_PREPROCESSING and SEARCH_INCLUDES tags are

set to YES then doxygen will generate a graph for each documented file showing the direct and indirect
include dependencies of the file with other documented files.
INCLUDED_BY_GRAPH If the INCLUDED_BY_GRAPH, ENABLE_PREPROCESSING and SEARCH_INCLUDES

tags are set to YES then doxygen will generate a graph for each documented file showing the direct and
indirect include dependencies of the file with other documented files.
CALL_GRAPH If the CALL_GRAPH tag is set to YES then doxygen will generate a call dependency graph for
every global function or class method.
Note that enabling this option will significantly increase the time of a run. So in most cases it will be better to
enable call graphs for selected functions only using the \callgraph command. Disabling a call graph can be
accomplished by means of the command \hidecallgraph.
CALLER_GRAPH If the CALLER_GRAPH tag is set to YES then doxygen will generate a caller dependency graph
for every global function or class method.
Note that enabling this option will significantly increase the time of a run. So in most cases it will be better
to enable caller graphs for selected functions only using the \callergraph command. Disabling a caller graph
can be accomplished by means of the command \hidecallergraph.
GRAPHICAL_HIERARCHY If the GRAPHICAL_HIERARCHY tag is set to YES then doxygen will graphical hi-
erarchy of all classes instead of a textual one.
DIRECTORY_GRAPH If the DIRECTORY_GRAPH tag is set to YES then doxygen will show the dependencies
a directory has on other directories in a graphical way. The dependency relations are determined by the
#include relations between the files in the directories.
DIR_GRAPH_MAX_DEPTH The DIR_GRAPH_MAX_DEPTH tag can be used to limit the maximum number of
levels of child directories generated in directory dependency graphs by dot.
This tag requires that the tag DIRECTORY_GRAPH is set to YES.

154 Configuration
DOT_IMAGE_FORMAT The DOT_IMAGE_FORMAT tag can be used to set the image format of the images gen-
erated by dot. For an explanation of the image formats see the section output formats in the documentation
of the dot tool ( Graphviz).
Note
If you choose svg you need to set HTML_FILE_EXTENSION to xhtml in order to make the SVG files
visible in IE 9+ (other browsers do not have this requirement).
Possible values are: png, jpg, gif, svg, png:gd, png:gd:gd, png:cairo, png:cairo:gd,
png:cairo:cairo, png:cairo:gdiplus, png:gdiplus and png:gdiplus:gdiplus.
The default value is: png.
INTERACTIVE_SVG If DOT_IMAGE_FORMAT is set to svg, then this option can be set to YES to enable
generation of interactive SVG images that allow zooming and panning.
Note that this requires a modern browser other than Internet Explorer. Tested and working are Firefox,
Chrome, Safari, and Opera.
Note
For IE 9+ you need to set HTML_FILE_EXTENSION to xhtml in order to make the SVG files visible.
Older versions of IE do not have SVG support.

DOT_PATH The DOT_PATH tag can be used to specify the path where the dot tool can be found. If left blank, it
is assumed the dot tool can be found in the path.
DOTFILE_DIRS The DOTFILE_DIRS tag can be used to specify one or more directories that contain dot files
that are included in the documentation (see the \dotfile command).
DIA_PATH You can include diagrams made with dia in doxygen documentation. Doxygen will then run dia to
produce the diagram and insert it in the documentation. The DIA_PATH tag allows you to specify the directory
where the dia binary resides. If left empty dia is assumed to be found in the default search path.
DIAFILE_DIRS The DIAFILE_DIRS tag can be used to specify one or more directories that contain dia files
that are included in the documentation (see the \diafile command).
PLANTUML_JAR_PATH When using plantuml, the PLANTUML_JAR_PATH tag should be used to specify the
path where java can find the plantuml.jar file or to the filename of jar file to be used. If left blank, it is
assumed PlantUML is not used or called during a preprocessing step. Doxygen will generate a warning when
it encounters a \startuml command in this case and will not generate output for the diagram.
PLANTUML_CFG_FILE When using plantuml, the PLANTUML_CFG_FILE tag can be used to specify a con-
figuration file for plantuml.
PLANTUML_INCLUDE_PATH When using plantuml, the specified paths are searched for files specified by the
!include statement in a plantuml block.
DOT_GRAPH_MAX_NODES The DOT_GRAPH_MAX_NODES tag can be used to set the maximum number of
nodes that will be shown in the graph. If the number of nodes in a graph becomes larger than this value,
doxygen will truncate the graph, which is visualized by representing a node as a red box. Note that doxygen
if the number of direct children of the root node in a graph is already larger than DOT_GRAPH_MAX_←-
NODES then the graph will not be shown at all. Also note that the size of a graph can be further restricted by
MAX_DOT_GRAPH_DEPTH.

23.20 Examples 155
MAX_DOT_GRAPH_DEPTH The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the
graphs generated by dot. A depth value of 3 means that only nodes reachable from the root by following a
path via at most 3 edges will be shown. Nodes that lay further from the root node will be omitted. Note that
setting this option to 1 or 2 may greatly reduce the computation time needed for large code bases. Also note
that the size of a graph can be further restricted by DOT_GRAPH_MAX_NODES. Using a depth of 0 means
no depth restriction.
DOT_MULTI_TARGETS Set the DOT_MULTI_TARGETS tag to YES to allow dot to generate multiple output
files in one run (i.e. multiple -o and -T options on the command line). This makes dot run faster, but since
only newer versions of dot (>1.8.10) support this, this feature is disabled by default.
GENERATE_LEGEND If the GENERATE_LEGEND tag is set to YES doxygen will generate a legend page ex-
plaining the meaning of the various boxes and arrows in the dot generated graphs.
Note
This tag requires that UML_LOOK isn't set, i.e. the doxygen internal graphical representation for inheri-
tance and collaboration diagrams is used.

DOT_CLEANUP If the DOT_CLEANUP tag is set to YES, doxygen will remove the intermediate files that are used
to generate the various graphs.
Note: This setting is not only used for dot files but also for msc temporary files.
MSCGEN_TOOL You can define message sequence charts within doxygen comments using the \msc command.
If the MSCGEN_TOOL tag is left empty (the default), then doxygen will use a built-in version of mscgen tool
to produce the charts. Alternatively, the MSCGEN_TOOL tag can also specify the name an external tool. For
instance, specifying prog as the value, doxygen will call the tool as prog -T <outfile_format>
-o <outputfile> <inputfile>. The external tool should support output file formats ¨png¨, ëps¨,
¨svg¨, and ïsmap¨.
MSCFILE_DIRS The MSCFILE_DIRS tag can be used to specify one or more directories that contain msc files
that are included in the documentation (see the \mscfile command).
23.20 Examples
Suppose you have a simple project consisting of two files: a source file example.cc and a header file
example.h. Then a minimal configuration file is as simple as:
INPUT = example.cc example.h
Assuming the example makes use of Qt classes and perl is located in /usr/bin, a more realistic configuration
file would be:
PROJECT_NAME = Example
INPUT = example.cc example.h
WARNINGS = YES
TAGFILES = qt.tag
SEARCHENGINE = NO
To generate the documentation for the QdbtTabular package I have used the following configuration file:

156 Configuration
PROJECT_NAME = QdbtTabular
OUTPUT_DIRECTORY = html
WARNINGS = YES
INPUT = examples/examples.doc src
FILE_PATTERNS = *.cc *.h
INCLUDE_PATH = examples
TAGFILES = qt.tag
SEARCHENGINE = YES
To regenerate the Qt-1.44 documentation from the sources, you could use the following configuration file:
PROJECT_NAME = Qt
OUTPUT_DIRECTORY = qt_docs
HIDE_UNDOC_MEMBERS = YES
HIDE_UNDOC_CLASSES = YES
SEARCH_INCLUDES = YES
FULL_PATH_NAMES = YES
STRIP_FROM_PATH = $(QTDIR)/
PREDEFINED = USE_TEMPLATECLASS Q_EXPORT= \
QArrayT:=QArray \
QListT:=QList \
QDictT:=QDict \
QQueueT:=QQueue \
QVectorT:=QVector \
QPtrDictT:=QPtrDict \
QIntDictT:=QIntDict \
QStackT:=QStack \
QDictIteratorT:=QDictIterator \
QListIteratorT:=QListIterator \
QCacheT:=QCache \
QCacheIteratorT:=QCacheIterator \
QIntCacheT:=QIntCache \
QIntCacheIteratorT:=QIntCacheIterator \
QIntDictIteratorT:=QIntDictIterator \
QPtrDictIteratorT:=QPtrDictIterator
INPUT = $(QTDIR)/doc \
$(QTDIR)/src/widgets \
$(QTDIR)/src/kernel \
$(QTDIR)/src/dialogs \
$(QTDIR)/src/tools
FILE_PATTERNS = *.cpp *.h q*.doc
INCLUDE_PATH = $(QTDIR)/include
RECURSIVE = YES
For the Qt-2.1 sources I recommend to use the following settings:
PROJECT_NAME = Qt
PROJECT_NUMBER = 2.1
HIDE_UNDOC_MEMBERS = YES
HIDE_UNDOC_CLASSES = YES
SOURCE_BROWSER = YES
INPUT = $(QTDIR)/src
FILE_PATTERNS = *.cpp *.h q*.doc
RECURSIVE = YES
EXCLUDE_PATTERNS = *codec.cpp moc_* */compat/* */3rdparty/*
ALPHABETICAL_INDEX = YES
IGNORE_PREFIX = Q
INCLUDE_PATH = $(QTDIR)/include
PREDEFINED = Q_PROPERTY(x)= \
Q_OVERRIDE(x)= \
Q_EXPORT= \
Q_ENUMS(x)= \
"QT_STATIC_CONST=static const " \
_WS_X11_ \
INCLUDE_MENUITEM_DEF

23.20 Examples 157
EXPAND_AS_DEFINED = Q_OBJECT_FAKE Q_OBJECT ACTIVATE_SIGNAL_WITH_PARAM \

Q_VARIANT_AS
Here doxygen's preprocessor is used to substitute some macro names that are normally substituted by the C
preprocessor, but without doing full macro expansion.

158 Configuration

Chapter 24
Special Commands
24.1 Introduction
All commands in the documentation start with a backslash (\) or an at-sign (@). If you prefer you can replace all
commands starting with a backslash below by their counterparts that start with an at-sign.
Some commands have one or more arguments. Each argument has a certain range:
• If <sharp> braces are used the argument is a single word.
• If (round) braces are used the argument extends until the end of the line on which the command was found.
• If {curly} braces are used the argument extends until the next paragraph. Paragraphs are delimited by a blank
line or by a section indicator. Note that {curly} braces are also used for command options, here the braces
are mandatory and just 'normal' characters. The starting curly brace has to directly follow the command, so
without whitespace.
If in addition to the above argument specifiers [square] brackets are used the argument is optional, unless they are
placed between quotes in that case they are a mandatory part of the command argument.
Here is an alphabetically sorted list of all commands with references to their documentation:
\a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.141
. \details . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.72
\addindex . . . . . . . . . . . . . . . . . . . . . . . . . 24.108
. \diafile . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.156
.
\addtogroup . . . . . . . . . . . . . . . . . . . . . . . . . 24.2 \dir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.17
\anchor . . . . . . . . . . . . . . . . . . . . . . . . . . 24.109
. \docbookinclude . . . . . . . . . . . . . . . . . . . . . . 24.139
.
\arg . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.142
. \docbookonly . . . . . . . . . . . . . . . . . . . . . . . 24.149
.
\attention . . . . . . . . . . . . . . . . . . . . . . . . . . .24.62 \dontinclude . . . . . . . . . . . . . . . . . . . . . . . . 24.123
.
\author . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.63 \dot . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.150
.
\authors . . . . . . . . . . . . . . . . . . . . . . . . . . .24.64 \dotfile . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.154
.
\b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.143
. \doxyconfig . . . . . . . . . . . . . . . . . . . . . . . . 24.157
.
\brief . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.65 \e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.158
.
\bug . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.66 \else . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.75
\c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.144
. \elseif . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.76
\callergraph . . . . . . . . . . . . . . . . . . . . . . . . . 24.5 \em . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.159
.
\callgraph . . . . . . . . . . . . . . . . . . . . . . . . . . 24.3 \emoji . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.151
.
\category . . . . . . . . . . . . . . . . . . . . . . . . . . .24.12 \endcode . . . . . . . . . . . . . . . . . . . . . . . . . . 24.160
.
\cite . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.110
. \endcond . . . . . . . . . . . . . . . . . . . . . . . . . . .24.77
\class . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.13 \enddocbookonly . . . . . . . . . . . . . . . . . . . . . 24.161
.
\code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.145
. \enddot . . . . . . . . . . . . . . . . . . . . . . . . . . 24.162
.
\concept . . . . . . . . . . . . . . . . . . . . . . . . . . .24.14 \endhtmlonly . . . . . . . . . . . . . . . . . . . . . . . . 24.165
.
\cond . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.67 \endif . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.78
\copybrief . . . . . . . . . . . . . . . . . . . . . . . . . 24.147
. \endinternal . . . . . . . . . . . . . . . . . . . . . . . . .24.20
\copydetails . . . . . . . . . . . . . . . . . . . . . . . . 24.148
. \endlatexonly . . . . . . . . . . . . . . . . . . . . . . . 24.166
.
\copydoc . . . . . . . . . . . . . . . . . . . . . . . . . . 24.146
. \endlink . . . . . . . . . . . . . . . . . . . . . . . . . . 24.111
.
\copyright . . . . . . . . . . . . . . . . . . . . . . . . . .24.68 \endmanonly . . . . . . . . . . . . . . . . . . . . . . . . 24.167
.
\date . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.69 \endmsc . . . . . . . . . . . . . . . . . . . . . . . . . . 24.163
.
\def . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.15 \endparblock . . . . . . . . . . . . . . . . . . . . . . . . .24.87
\defgroup . . . . . . . . . . . . . . . . . . . . . . . . . .24.16 \endrtfonly . . . . . . . . . . . . . . . . . . . . . . . . . 24.168
.
\deprecated . . . . . . . . . . . . . . . . . . . . . . . . .24.71 \endsecreflist . . . . . . . . . . . . . . . . . . . . . . . 24.116
.

160 Special Commands
\endverbatim . . . . . . . . . . . . . . . . . . . . . . . . 24.169
. \pure . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.49
\enduml . . . . . . . . . . . . . . . . . . . . . . . . . . 24.164
. \qualifier . . . . . . . . . . . . . . . . . . . . . . . . . . .24.11
\endxmlonly . . . . . . . . . . . . . . . . . . . . . . . . 24.170
. \raisewarning . . . . . . . . . . . . . . . . . . . . . . . .24.74
\enum . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.18 \ref . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.113
.
\example . . . . . . . . . . . . . . . . . . . . . . . . . . .24.19 \refitem . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.114
.
\exception . . . . . . . . . . . . . . . . . . . . . . . . . .24.79 \related . . . . . . . . . . . . . . . . . . . . . . . . . . .24.51
\extends . . . . . . . . . . . . . . . . . . . . . . . . . . .24.21 \relates . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.50
\f( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.172
. \relatedalso . . . . . . . . . . . . . . . . . . . . . . . . .24.53
\f) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.173
. \relatesalso . . . . . . . . . . . . . . . . . . . . . . . . .24.52
\f$ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.171
. \remark . . . . . . . . . . . . . . . . . . . . . . . . . . .24.91
\f[ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.174
. \remarks . . . . . . . . . . . . . . . . . . . . . . . . . . .24.92
\f] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.175
. \result . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.93
\f{ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.176
. \return . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.94
\f} . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.177
. \returns . . . . . . . . . . . . . . . . . . . . . . . . . . .24.95
\file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.22 \retval . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.96
\fileinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.23 \rtfinclude . . . . . . . . . . . . . . . . . . . . . . . . . 24.137
.
\fn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.25 \rtfonly . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.185
.
\headerfile . . . . . . . . . . . . . . . . . . . . . . . . . .24.26 \sa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.97
\hidecallergraph . . . . . . . . . . . . . . . . . . . . . . . 24.6 \secreflist . . . . . . . . . . . . . . . . . . . . . . . . . 24.115
.
\hidecallgraph . . . . . . . . . . . . . . . . . . . . . . . . 24.4 \section . . . . . . . . . . . . . . . . . . . . . . . . . . 24.119
.
\hiderefby . . . . . . . . . . . . . . . . . . . . . . . . . . 24.8 \see . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.98
\hiderefs . . . . . . . . . . . . . . . . . . . . . . . . . . .24.10 \short . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.99
\hideinitializer . . . . . . . . . . . . . . . . . . . . . . . .24.27 \showdate . . . . . . . . . . . . . . . . . . . . . . . . . .24.70
\htmlinclude . . . . . . . . . . . . . . . . . . . . . . . . 24.135
. \showinitializer . . . . . . . . . . . . . . . . . . . . . . . .24.54
\htmlonly . . . . . . . . . . . . . . . . . . . . . . . . . . 24.178
. \showrefby . . . . . . . . . . . . . . . . . . . . . . . . . . 24.7
\idlexcept . . . . . . . . . . . . . . . . . . . . . . . . . .24.28 \showrefs . . . . . . . . . . . . . . . . . . . . . . . . . . 24.9
\if . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.80 \since . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.100
.
\ifnot . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.81 \skip . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.128
.
\image . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.179
. \skipline . . . . . . . . . . . . . . . . . . . . . . . . . . 24.129
.
\implements . . . . . . . . . . . . . . . . . . . . . . . . .24.29 \snippet . . . . . . . . . . . . . . . . . . . . . . . . . . 24.130
.
\include . . . . . . . . . . . . . . . . . . . . . . . . . . 24.124
. \snippetdoc . . . . . . . . . . . . . . . . . . . . . . . . 24.132
.
\includedoc . . . . . . . . . . . . . . . . . . . . . . . . 24.126
. \snippetlineno . . . . . . . . . . . . . . . . . . . . . . . 24.131
.
\includelineno . . . . . . . . . . . . . . . . . . . . . . . 24.125
. \static . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.55
\ingroup . . . . . . . . . . . . . . . . . . . . . . . . . . .24.30 \startuml . . . . . . . . . . . . . . . . . . . . . . . . . . 24.153
.
\internal . . . . . . . . . . . . . . . . . . . . . . . . . . .24.32 \struct . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.56
\invariant . . . . . . . . . . . . . . . . . . . . . . . . . . .24.82 \subpage . . . . . . . . . . . . . . . . . . . . . . . . . . 24.117
.
\interface . . . . . . . . . . . . . . . . . . . . . . . . . . .24.31 \subsection . . . . . . . . . . . . . . . . . . . . . . . . 24.120
.
\latexinclude . . . . . . . . . . . . . . . . . . . . . . . . 24.136
. \subsubsection . . . . . . . . . . . . . . . . . . . . . . 24.121
.
\latexonly . . . . . . . . . . . . . . . . . . . . . . . . . 24.180
. \tableofcontents . . . . . . . . . . . . . . . . . . . . . . 24.118
.
\li . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.182
. \test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.101
.
\line . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.127
. \throw . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.102
.
\lineinfo . . . . . . . . . . . . . . . . . . . . . . . . . . .24.24 \throws . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.103
.
\link . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.112
. \todo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.104
.
\mainpage . . . . . . . . . . . . . . . . . . . . . . . . . .24.33 \tparam . . . . . . . . . . . . . . . . . . . . . . . . . . .24.88
\maninclude . . . . . . . . . . . . . . . . . . . . . . . . 24.138
. \typedef . . . . . . . . . . . . . . . . . . . . . . . . . . .24.57
\manonly . . . . . . . . . . . . . . . . . . . . . . . . . . 24.181
. \union . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.58
\memberof . . . . . . . . . . . . . . . . . . . . . . . . . .24.34 \until . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.133
.
\msc . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.152
. \var . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.59
\mscfile . . . . . . . . . . . . . . . . . . . . . . . . . . 24.155
. \verbatim . . . . . . . . . . . . . . . . . . . . . . . . . . 24.186
.
\n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.183
. \verbinclude . . . . . . . . . . . . . . . . . . . . . . . . 24.134
.
\name . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.35 \version . . . . . . . . . . . . . . . . . . . . . . . . . . 24.105
.
\namespace . . . . . . . . . . . . . . . . . . . . . . . . .24.36 \vhdlflow . . . . . . . . . . . . . . . . . . . . . . . . . . .24.60
\noop . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.73 \warning . . . . . . . . . . . . . . . . . . . . . . . . . . 24.106
.
\nosubgrouping . . . . . . . . . . . . . . . . . . . . . . .24.37 \weakgroup . . . . . . . . . . . . . . . . . . . . . . . . .24.61
\note . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.83 \xmlinclude . . . . . . . . . . . . . . . . . . . . . . . . . 24.140
.
\overload . . . . . . . . . . . . . . . . . . . . . . . . . . .24.38 \xmlonly . . . . . . . . . . . . . . . . . . . . . . . . . . 24.187
.
\p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.184
. \xrefitem . . . . . . . . . . . . . . . . . . . . . . . . . . 24.107
.
\package . . . . . . . . . . . . . . . . . . . . . . . . . . .24.39 \$ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.192
.
\page . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.40 \@ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.189
.
\par . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.84 \\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.188
.
\paragraph . . . . . . . . . . . . . . . . . . . . . . . . . 24.122
. \& . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.191
.
\param . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.85 \∼ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.190
.
\parblock . . . . . . . . . . . . . . . . . . . . . . . . . . .24.86 \< . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.194
.
\post . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.89 \= . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.199
.
\pre . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.90 \> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.195
.
\private . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.41 \# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.193
.
\privatesection . . . . . . . . . . . . . . . . . . . . . . . .24.42 \% . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.196
.
\property . . . . . . . . . . . . . . . . . . . . . . . . . . .24.43 \" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.197
.
\protected . . . . . . . . . . . . . . . . . . . . . . . . . .24.44 \. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.198
.
\protectedsection . . . . . . . . . . . . . . . . . . . . . .24.45 \:: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.200
.
\protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .24.46 \| . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.201
.
\public . . . . . . . . . . . . . . . . . . . . . . . . . . . .24.47 \-- . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.202
.
\publicsection . . . . . . . . . . . . . . . . . . . . . . . .24.48 \--- . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.203
.

24.2 \addtogroup <name> [(title)] 161
The following subsections provide a list of all commands that are recognized by doxygen. Unrecognized commands
are treated as normal text.
Structural indicators
24.2 \addtogroup <name> [(title)]
Defines a group just like \defgroup, but in contrast to that command using the same <name> more than once will
not result in a warning, but rather one group with a merged documentation and the first title found in any of the
commands.
The title is optional, so this command can also be used to add a number of entities to an existing group using @{
and @} like this:
/*! \addtogroup mygrp

* Additional documentation for group ’mygrp’
* @{
*/
/*!
* A function
*/
void func1()
{
}
/*! Another function */

void func2()
{
}
/*! @} */
See also
page Grouping, sections \defgroup, \ingroup, and \weakgroup.
24.3 \callgraph
When this command is put in a comment block of a function or method and HAVE_DOT is set to YES, then doxy-
gen will generate a call graph for that function (provided the implementation of the function or method calls other
documented functions). The call graph will be generated regardless of the value of CALL_GRAPH.
Note
The completeness (and correctness) of the call graph depends on the doxygen code parser which is not
perfect.
See also
section \callergraph, section \hidecallgraph, section \hidecallergraph and option CALL_GRAPH
24.4 \hidecallgraph
When this command is put in a comment block of a function or method and then doxygen will not generate a call
graph for that function. The call graph will not be generated regardless of the value of CALL_GRAPH.

Note
The completeness (and correctness) of the call graph depends on the doxygen code parser which is not
perfect.
See also
section \callergraph, section \callgraph, section \hidecallergraph and option CALL_GRAPH
24.5 \callergraph
When this command is put in a comment block of a function or method and HAVE_DOT is set to YES, then doxygen
will generate a caller graph for that function (provided the implementation of the function or method is called by other
documented functions). The caller graph will be generated regardless of the value of CALLER_GRAPH.
Note
The completeness (and correctness) of the caller graph depends on the doxygen code parser which is not
perfect.
See also
section \callgraph, section \hidecallgraph, section \hidecallergraph and option CALLER_GRAPH
24.6 \hidecallergraph
When this command is put in a comment block of a function or method and then doxygen will not generate a caller
graph for that function. The caller graph will not be generated regardless of the value of CALLER_GRAPH.
Note
The completeness (and correctness) of the caller graph depends on the doxygen code parser which is not
perfect.
See also
section \callergraph, section \callgraph, section \hidecallgraph and option CALLER_GRAPH
24.7 \showrefby
When this command is put in a comment block of a function, method or variable, then doxygen will generate an
overview for that function, method, variable of the, documented, functions and methods that call / use it. The
overview will be generated regardless of the value of REFERENCED_BY_RELATION.
Note
The completeness (and correctness) of the overview depends on the doxygen code parser which is not perfect.
See also
section \showrefs, section \hiderefby, section \hiderefs and option REFERENCED_BY_RELATION
24.8 \hiderefby
When this command is put in a comment block of a function, method or variable then doxygen will not generate an
overview for that function, method or variable of the functions and methods that call / use it. The overview will not
be generated regardless of the value of REFERENCED_BY_RELATION.
Note
See also
section \showrefs, section \showrefby, section \hiderefs and option REFERENCED_BY_RELATION

24.9 \showrefs 163
24.9 \showrefs
When this command is put in a comment block of a function or method, then doxygen will generate an overview for
that function or method of the functions and methods that call it. The overview will be generated regardless of the
value of REFERENCES_RELATION.
Note
See also
section \showrefby, section \hiderefby, section \hiderefs and option REFERENCES_RELATION
24.10 \hiderefs
When this command is put in a comment block of a function or method and then doxygen will not generate an
overview for that function or method of the functions and methods that call it. The overview will not be generated
regardless of the value of REFERENCES_RELATION.
Note
See also
section \showrefs, section \showrefby, section \hiderefby and option REFERENCES_RELATION
24.11 \qualifier <label> | ¨(text)¨

With this command it is possible to add custom qualifier labels to members and classes. These labels will be shown
in the output in the same way as the automatically generated labels such as ¨static¨, ïnline¨, and ¨final¨.
For instance to indicate that a function is only meant for testing purposes one could add \qualifier test
24.12 \category <name> [<header-file>] [<header-name>]

For Objective-C only: Indicates that a comment block contains documentation for a class category with name
<name>. The arguments are equal to the \class command.
See also
section \class.
24.13 \class <name> [<header-file>] [<header-name>]

Indicates that a comment block contains documentation for a class with name <name>. Optionally a header file
and a header name can be specified. If the header-file is specified, a link to a verbatim copy of the header will
be included in the HTML documentation. The <header-name> argument can be used to overwrite the name of
the link that is used in the class documentation to something other than <header-file>. This can be useful if the
include name is not located on the default include path (like <X11/X.h>). With the <header-name> argument you
can also specify how the include statement should look like, by adding either quotes or sharp brackets around the
name. Sharp brackets are used if just the name is given. Note that the last two arguments can also be specified
using the \headerfile command.

Example:
/* A dummy class */
class Test
{
};
/*! \class Test class.h "inc/class.h"

* \brief This is a test class.
*
* Some details about the Test class.
*/
See Class example for the corresponding LATEX documentation that is generated by doxygen.
24.14 \concept <name>

Indicates that a comment block contains documentation for a C++20 concept with name <name>. See also the
\headerfile command to specify the header a user should be included to use the concept.
24.15 \def <name>

Indicates that a comment block contains documentation for a #define macro.
Example:
/*! \file define.h

\brief testing defines
This is to test the documentation of defines.

*/
/*!
\def MAX(x,y)
Computes the maximum of \a x and \a y.
*/
/*!
\brief Computes the absolute value of its argument \a x.
\param x input value.
\returns absolute value of \a x.
*/
#define ABS(x) (((x)>0)?(x):-(x))
#define MAX(x,y) ((x)>(y)?(x):(y))
#define MIN(x,y) ((x)>(y)?(y):(x))
/*!< Computes the minimum of \a x and \a y. */
See Define example for the corresponding LATEX documentation that is generated by doxygen.
24.16 \defgroup <name> (group title)

Indicates that a comment block contains documentation for a group of classes, files or namespaces. This can be
used to categorize classes, files or namespaces, and document those categories. You can also use groups as
members of other groups, thus building a hierarchy of groups.
The <name> argument should be a single-word identifier.
See also
page Grouping, sections \ingroup, \addtogroup, and \weakgroup.
24.17 \dir [<path fragment>]

Indicates that a comment block contains documentation for a directory. The ¨path fragment¨ argument should
include the directory name and enough of the path to be unique with respect to the other directories in the project.
The STRIP_FROM_PATH option determines what is stripped from the full path before it appears in the output.

24.18 \enum <name> 165
24.18 \enum <name>

Indicates that a comment block contains documentation for an enumeration, with name <name>. If the enum is a
member of a class and the documentation block is located outside the class definition, the scope of the class should
be specified as well. If a comment block is located directly in front of an enum declaration, the \enum comment
may be omitted.
Note:
The type of an anonymous enum cannot be documented, but the values of an anonymous enum can.
Example:
class Enum_Test
{
public:
enum TEnum { Val1, Val2 };
/*! Another enum, with inline docs */

enum AnotherEnum
{
V1, /*!< value 1 */
V2 /*!< value 2 */
};
};
/*! \class Enum_Test

* The class description.
*/
/*! \enum Enum_Test::TEnum

* A description of the enum type.
*/
/*! \var Enum_Test::TEnum Enum_Test::Val1

* The description of the first enum value.
*/
See Enum example for the corresponding LATEX documentation that is generated by doxygen.
24.19 \example['{lineno}'] <file-name>

Indicates that a comment block contains documentation for a source code example. The name of the source file is
<file-name>. The contents of this file will be included in the documentation, just after the documentation contained
in the comment block. You can add option {lineno} to enable line numbers for the example if desired. All
examples are placed in a list. The source code is scanned for documented members and classes. If any are found,
the names are cross-referenced with the documentation. Source files or directories can be specified using the
EXAMPLE_PATH tag of doxygen's configuration file.
If <file-name> itself is not unique for the set of example files specified by the EXAMPLE_PATH tag, you can include
part of the absolute path to disambiguate it.
If more than one source file is needed for the example, the \include command can be used.
Example:
/** A Example_Test class.

* More details about this class.
*/
class Example_Test
{
public:
/** An example member function.
* More details about this function.
*/
void example();
};
void Example_Test::example() {}
/** \example example_test.cpp

* This is an example of how to use the Example_Test class.
* More details about this example.
*/
Where the example file example_test.cpp looks as follows:

void main()
{
Example_Test t;
t.example();
}
See Example example for the corresponding LATEX documentation that is generated by doxygen.
See also
section \include.
24.20 \endinternal
This command ends a documentation fragment that was started with a \internal command. The text between
\internal and \endinternal will only be visible if INTERNAL_DOCS is set to YES.
24.21 \extends <name>

This command can be used to manually indicate an inheritance relation, when the programming language does not
support this concept natively (e.g. C).
The file manual.c in the example directory shows how to use this command (see also \memberof for the complete
file).
See Extends example for the corresponding LATEX documentation that is generated by doxygen.
See also
section \implements and section \memberof
24.22 \file [<name>]

Indicates that a comment block contains documentation for a source or header file with name <name>. The file
name may include (part of) the path if the file-name alone is not unique. If the file name is omitted (i.e. the line after
\file is left blank) then the documentation block that contains the \file command will belong to the file it is
located in.
Important:
The documentation of global functions, variables, typedefs, and enums will only be included in the output if
the file they are in is documented as well or if EXTRACT_ALL is set to YES.
Example:
/** \file file.h

* A brief file description.
* A more elaborated file description.
*/
/**
* A global integer value.
* More details about this value.
*/
extern int globalValue;
See File example for the corresponding LATEX documentation that is generated by doxygen.
Note
In the above example JAVADOC_AUTOBRIEF has been set to YES in the configuration file.

24.23 \fileinfo['{'option'}'] 167
24.23 \fileinfo['{'option'}']
Shows (part) of the file name in which this command is placed. The option can be name, extension,
filename, directory or, full, with
• name the name of the file without extension
• extension the extension of the file
• filename the filename i.e. name plus extension
• directory the directory of the given file
• full the full path and filename of the given file.
In case no option is specified the filename is used unless FULL_PATH_NAMES is set to YES in which case
full is used.
Note
the command \fileinfo cannot be used as argument to the \file command
See also
section \lineinfo
24.24 \lineinfo
Shows the line number inside the file at which this command is placed.
See also
section \fileinfo
24.25 \fn (function declaration)

Indicates that a comment block contains documentation for a function (either global or as a member of a class). This
command is only needed if a comment block is not placed in front (or behind) the function declaration or definition.
If your comment block is in front of the function declaration or definition this command can (and to avoid redundancy
should) be omitted.
A full function declaration including arguments should be specified after the \fn command on a single line, since
the argument ends at the end of the line!
This command is equivalent to \var, \typedef, and \property.
Warning
Do not use this command if it is not absolutely needed, since it will lead to duplication of information and thus
to errors.
Example:
class Fn_Test
{
public:
const char *member(char,int) throw(std::out_of_range);
};
const char *Fn_Test::member(char c,int n) throw(std::out_of_range) {}
/*! \class Fn_Test

* \brief Fn_Test class.
*
* Details about Fn_Test.
*/
/*! \fn const char *Fn_Test::member(char c,int n)

* \brief A member function.
* \param c a character.

* \param n an integer.
* \exception std::out_of_range parameter is out of range.
* \return a character pointer.
*/
See Fn example for the corresponding LATEX documentation that is generated by doxygen.
See also
sections \var, \property, and \typedef.
24.26 \headerfile <header-file> [<header-name>]

Intended to be used for class, struct, or union documentation, where the documentation is in front of the definition.
The arguments of this command are the same as the second and third argument of \class. The <header-file> name
refers to the file that should be included by the application to obtain the definition of the class, struct, or union. The
<header-name> argument can be used to overwrite the name of the link that is used in the class documentation
to something other than <header-file>. This can be useful if the include name is not located on the default include
path (like <X11/X.h>).
With the <header-name> argument you can also specify how the include statement should look like, by adding
either double quotes or sharp brackets around the name. By default sharp brackets are used if just the name is
given.
If a pair of double quotes is given for either the <header-file> or <header-name> argument, the current file (in
which the command was found) will be used but with quotes. So for a comment block with a \headerfile
command inside a file test.h, the following three commands are equivalent:
\headerfile test.h "test.h"
\headerfile test.h ""
\headerfile ""
To get sharp brackets you do not need to specify anything, but if you want to be explicit you could use any of the
following:
\headerfile test.h <test.h>
\headerfile test.h <>
\headerfile <>
To globally reverse the default include representation to local includes you can set FORCE_LOCAL_INCLUDES to
YES.
To disable the include information altogether set SHOW_HEADERFILE to NO.
24.27 \hideinitializer
By default the value of a define and the initializer of a variable are displayed unless they are longer than 30 lines.
By putting this command in a comment block of a define or variable, the initializer is always hidden. The maximum
number of initialization lines can be changed by means of the configuration parameter MAX_INITIALIZER_LINES,
the default value is 30.
See also
section \showinitializer.
24.28 \idlexcept <name>

Indicates that a comment block contains documentation for a IDL exception with name <name>.
24.29 \implements <name>

This command can be used to manually indicate an inheritance relation, when the programming language does not
support this concept natively (e.g. C).
The file manual.c in the example directory shows how to use this command (see also \memberof for the complete
file).
See Implements example for the corresponding LATEX documentation that is generated by doxygen.

24.30 \ingroup (<groupname> [<groupname>]∗) 169
See also
section \extends and section \memberof
24.30 \ingroup (<groupname> [<groupname>]∗)

If the \ingroup command is placed in a comment block of a compound entity (like class, file or namespace), then
it will be added to the group(s) identified by the <groupname>(s). In case of members (like variable, functions,
typedefs and enums) the member will be added only to one group (to avoid ambiguous linking targets in case a
member is not documented in the context of its class, namespace or file, but only visible as part of a group).
See also
page Grouping, sections \defgroup, \addtogroup, and \weakgroup
24.31 \interface <name> [<header-file>] [<header-name>]

Indicates that a comment block contains documentation for an interface with name <name>. The arguments are
equal to the arguments of the \class command.
See also
section \class.
24.32 \internal
This command starts a documentation fragment that is meant for internal use only. The fragment naturally ends
at the end of the comment block. You can also force the internal section to end earlier by using the \endinternal
command.
If the \internal command is put inside a section (see for example \section) all subsections after the command
are considered to be internal as well. Only a new section at the same level will end the fragment that is considered
internal.
You can use INTERNAL_DOCS in the configuration file to show (YES) or hide (NO) the internal documentation.
See also
section \endinternal.
24.33 \mainpage [(title)]

If the \mainpage command is placed in a comment block the block is used to customize the index page (in HTML)
or the first chapter (in LATEX).
The title argument is optional and replaces the default title that doxygen normally generates. If you do not want any
title you can specify notitle as the argument of \mainpage.
Here is an example:
/*! \mainpage My Personal Index Page
*
* \section intro_sec Introduction
*
* This is the introduction.
*
* \section install_sec Installation
*
* \subsection step1 Step 1: Opening the box
*
* etc...
*/
You can refer to the main page using: \ref index.

See also
section \section, section \subsection, and section \page.

24.34 \memberof <name>

This command makes a function a member of a class in a similar way as \relates does, only with this command the
function is represented as a real member of the class. This can be useful when the programming language does
not support the concept of member functions natively (e.g. C).
It is also possible to use this command together with \public, \protected or \private.
Example:
The file manual.c in the example directory shows how to use this command:
/**
* \file manual.c
*/
typedef struct Object Object; //!< Object type

typedef struct Vehicle Vehicle; //!< Vehicle type
typedef struct Car Car; //!< Car type
typedef struct Truck Truck; //!< Truck type
/*!
* Base object class.
*/
struct Object
{
int ref; //!< \private Reference count.
};
/*!
* Increments object reference count by one.
* \public \memberof Object
*/
static Object * objRef(Object *obj);
/*!
* Decrements object reference count by one.
* \public \memberof Object
*/
static Object * objUnref(Object *obj);
/*!
* Vehicle class.
* \extends Object
*/
struct Vehicle
{
Object base; //!< \protected Base class.
};
/*!
* Starts the vehicle.
* \public \memberof Vehicle
*/
void vehicleStart(Vehicle *obj);
/*!
* Stops the vehicle.
* \public \memberof Vehicle
*/
void vehicleStop(Vehicle *obj);
/*!
* Car class.
* \extends Vehicle
*/
struct Car
{
Vehicle base; //!< \protected Base class.
};
/*!
* Truck class.
* \extends Vehicle
*/
struct Truck
{
Vehicle base; //!< \protected Base class.

24.35 \name [(header)] 171
};
/*!
* Main function.
*
* Ref vehicleStart(), objRef(), objUnref().
*/
int main(void)
{
Car c;
vehicleStart((Vehicle*) &c);
}
See Car struct reference example for the corresponding LATEX documentation that is generated by doxygen.
See also
sections \extends, \implements, \public, \protected and \private.
24.35 \name [(header)]

This command turns a comment block into a header definition of a member group. The comment block should be
followed by a @{ ... @} block containing the members of the group.
See section Member Groups for an example.
24.36 \namespace <name>

Indicates that a comment block contains documentation for a namespace with name <name>.
24.37 \nosubgrouping
This command can be put in the documentation of a class. It can be used in combination with member grouping to
avoid that doxygen puts a member group as a subgroup of a Public/Protected/Private/... section.
See also
sections \publicsection, \protectedsection and \privatesection.
24.38 \overload [(function declaration)]

This command can be used to generate the following standard text for an overloaded member function:
This is an overloaded member function, provided for convenience. It differs from the above function
only in what argument(s) it accepts.
If the documentation for the overloaded member function is not located in front of the function declaration or defini-
tion, the optional argument should be used to specify the correct declaration of the overloaded function. Of course
when the \overload command is directly in front of the overloaded member function and the optional argument
is used this should also be the correct declaration of the overloaded function.
Any other documentation that is inside the documentation block will by appended after the generated message.
Note 1:
You are responsible that there is indeed an earlier documented member that is overloaded by this one. To
prevent that document reorders the documentation you should set SORT_MEMBER_DOCS to NO in this case.
Note 2:
Only one \overload command can be present in a comment block.

Example:
class Overload_Test
{
public:
void drawRect(int,int,int,int);
void drawRect(const Rect &r);
};
void Overload_Test::drawRect(int x,int y,int w,int h) {}

void Overload_Test::drawRect(const Rect &r) {}
/*! \class Overload_Test

* \brief A short description.
*
* More text.
*/
/*! \fn void Overload_Test::drawRect(int x,int y,int w,int h)

* This command draws a rectangle with a left upper corner at ( \a x , \a y ),
* width \a w and height \a h.
*/
/*!
* \overload void Overload_Test::drawRect(const Rect &r)
*/
See Overload example for the corresponding LATEX documentation that is generated by doxygen.
24.39 \package <name>

Indicates that a comment block contains documentation for a Java package with name <name>.
24.40 \page <name> (title)

Indicates that a comment block contains a piece of documentation that is not directly related to one specific class,
file or member. The HTML generator creates a page containing the documentation. The LATEX generator starts a
new section in the chapter 'Page documentation'.
Example:
/*! \page page1 A documentation page

\tableofcontents
Leading text.
\section sec An example section
This page contains the subsections \ref subsection1 and \ref subsection2.
For more info see page \ref page2.
\subsection subsection1 The first subsection
Text.
\subsection subsection2 The second subsection
More text.
*/
/*! \page page2 Another page

Even more info.
*/
See Page example for the corresponding LATEX documentation that is generated by doxygen.
Note:
The <name> argument consists of a combination of letters and number digits. If you wish to use upper
case letters (e.g. MYPAGE1), or mixed case letters (e.g. MyPage1) in the <name> argument, you should
set CASE_SENSE_NAMES to YES. However, this is advisable only if your file system is case sensitive.
Otherwise (and for better portability) you should use all lower case letters (e.g. mypage1) for <name> in all
references to the page.
See also
section \section, section \subsection, and section \ref.

24.41 \private 173
24.41 \private
Indicates that the member documented by the comment block is private, i.e., should only be accessed by other
members in the same class.
Note that doxygen automatically detects the protection level of members in object-oriented languages. This com-
mand is intended for use only when the language does not support the concept of protection level natively (e.g. C,
PHP 4).
For starting a section of private members, in a way similar to the ¨private:¨ class marker in C++, use \privatesection.
See also
sections \memberof, \public, \protected and \privatesection.
24.42 \privatesection
Starting a section of private members, in a way similar to the ¨private:¨ class marker in C++. Indicates that the
member documented by the comment block is private, i.e., should only be accessed by other members in the same
class.
See also
sections \memberof, \public, \protected and \private.
24.43 \property (qualified property name)

Indicates that a comment block contains documentation for a property (either global or as a member of a class).
This command is equivalent to \fn, \typedef, and \var.
See also
sections \fn, \typedef, and \var.
24.44 \protected
Indicates that the member documented by the comment block is protected, i.e., should only be accessed by other
members in the same or derived classes.
PHP 4).
For starting a section of protected members, in a way similar to the ¨protected:¨ class marker in C++, use
\protectedsection.
See also
sections \memberof, \public, \private and \protectedsection.
24.45 \protectedsection
Starting a section of protected members, in a way similar to the ¨protected:¨ class marker in C++. Indicates that the
member documented by the comment block is protected, i.e., should only be accessed by other members in the
same or derived classes.
See also
sections \memberof, \public, \private and \protected.

24.46 \protocol <name> [<header-file>] [<header-name>]

Indicates that a comment block contains documentation for a protocol in Objective-C with name <name>. The
arguments are equal to the \class command.
See also
section \class.
24.47 \public
Indicates that the member documented by the comment block is public, i.e., can be accessed by any other class or
function.
PHP 4).
For starting a section of public members, in a way similar to the ¨public:¨ class marker in C++, use \publicsection.
See also
sections \memberof, \protected, \private and \publicsection.
24.48 \publicsection
Starting a section of public members, in a way similar to the ¨public:¨ class marker in C++. Indicates that the member
documented by the comment block is public, i.e., can be accessed by any other class or function.
See also
sections \memberof, \protected, \private and \public.
24.49 \pure
Indicates that the member documented by the comment block is pure virtual, i.e., it is abstract and has no imple-
mentation associated with it.
This command is intended for use only when the language does not support the concept of pure virtual methods
natively (e.g. C, PHP 4).
24.50 \relates <name>

This command can be used in the documentation of a non-member function <name>. It puts the function inside the
'related function' section of the class documentation. This command is useful for documenting non-friend functions
that are nevertheless strongly coupled to a certain class. It prevents the need of having to document a file, but only
works for functions.
Example:
/*!
* A String class.
*/
class String
{
friend int strcmp(const String &,const String &);
};
/*!
* Compares two strings.
*/
int strcmp(const String &s1,const String &s2)

{
}
/*! \relates String

24.51 \related <name> 175
* A string debug function.

*/
void stringDebug()
{
}
See Relates example for the corresponding LATEX documentation that is generated by doxygen.
24.51 \related <name>

Equivalent to \relates
24.52 \relatesalso <name>

This command can be used in the documentation of a non-member function <name>. It puts the function both
inside the 'related function' section of the class documentation as well as leaving it at its normal file documentation
location. This command is useful for documenting non-friend functions that are nevertheless strongly coupled to a
certain class. It only works for functions.
24.53 \relatedalso <name>

Equivalent to \relatesalso
24.54 \showinitializer
By default the value of a define and the initializer of a variable are only displayed if they are less than 30 lines
long. By putting this command in a comment block of a define or variable, the initializer is shown uncondi-
tionally. The maximum number of initialization lines can be changed by means of the configuration parameter
MAX_INITIALIZER_LINES, the default value is 30.
See also
section \hideinitializer.
24.55 \static
Indicates that the member documented by the comment block is static, i.e., it works on a class, instead of on an
instance of the class.
This command is intended for use only when the language does not support the concept of static methods natively
(e.g. C).
24.56 \struct <name> [<header-file>] [<header-name>]

Indicates that a comment block contains documentation for a struct with name <name>. The arguments are equal
to the arguments of the \class command.
See also
section \class.
24.57 \typedef (typedef declaration)

Indicates that a comment block contains documentation for a typedef (either global or as a member of a class). This
command is equivalent to \fn, \property, and \var.
See also
section \fn, \property, and \var.

24.58 \union <name> [<header-file>] [<header-name>]

Indicates that a comment block contains documentation for a union with name <name>. The arguments are equal
to the arguments of the \class command.
See also
section \class.
24.59 \var (variable declaration)

Indicates that a comment block contains documentation for a variable or enum value (either global or as a member
of a class). This command is equivalent to \fn, \property, and \typedef.
Note that for PHP one can also specify the type of the variable. The syntax is similar as for the phpDocumentor
but the description has to start at the next line, i.e.
@var datatype $varname

Description
See also
section \fn, \property, and \typedef.
24.60 \vhdlflow [(title for the flow chart)]

This is a VHDL specific command, which can be put in the documentation of a process to produce a flow chart of
the logic in the process. Optionally a title for the flow chart can be given.
Note
Currently the flow chart will only appear in the HTML output.
24.61 \weakgroup <name> [(title)]

Can be used exactly like \addtogroup, but has a lower priority when it comes to resolving conflicting grouping
definitions.
See also
page Grouping and section \addtogroup.
Section indicators
24.62 \attention { attention text }
Starts a paragraph where a message that needs attention may be entered. The paragraph will be indented. The
text of the paragraph has no special internal structure. All visual enhancement commands may be used inside the
paragraph. Multiple adjacent \attention commands will be joined into a single paragraph. The \attention
command ends when a blank line or some other sectioning command is encountered.
24.63 \author { list of authors }

Starts a paragraph where one or more author names may be entered. The paragraph will be indented. The text
of the paragraph has no special internal structure. All visual enhancement commands may be used inside the
paragraph. Multiple adjacent \author commands will be joined into a single paragraph. Each author description
will start a new line. Alternatively, one \author command may mention several authors. The \author command
ends when a blank line or some other sectioning command is encountered.

24.64 \authors { list of authors } 177
Example:
/*!
* \brief Pretty nice class.
* \details This class is used to demonstrate a number of section commands.
* \author John Doe
* \author Jan Doe
* \version 4.1a
* \date 1990-2011
* \pre First initialize the system.
* \bug Not all memory is freed when deleting an object of this class.
* \warning Improper use can crash your application
* \copyright GNU Public License.
*/
class SomeNiceClass {};
See Author example for the corresponding LATEX documentation that is generated by doxygen.
24.64 \authors { list of authors }

Equivalent to \author.
24.65 \brief { brief description }

Starts a paragraph that serves as a brief description. For classes and files the brief description will be used in lists
and at the start of the documentation page. For class and file members, the brief description will be placed at the
declaration of the member and prepended to the detailed description. A brief description may span several lines
(although it is advised to keep it brief!). A brief description ends when a blank line or another sectioning command
is encountered. If multiple \brief commands are present they will be joined. See section \author for an example.
Synonymous to \short.
24.66 \bug { bug description }

Starts a paragraph where one or more bugs may be reported. The paragraph will be indented. The text of the
paragraph has no special internal structure. All visual enhancement commands may be used inside the paragraph.
Multiple adjacent \bug commands will be joined into a single paragraph. Each bug description will start on a new
line. Alternatively, one \bug command may mention several bugs. The \bug command ends when a blank line or
some other sectioning command is encountered. See section \author for an example.
The description will also add an item to a separate Bug list and the two instances of the description will be cross-
referenced. Each item in the Bug list will be preceded by a header that indicates the origin of the item.
The Bug list and the corresponding entries can be disabled by setting the GENERATE_BUGLIST to NO.
24.67 \cond [(section-label)]

Starts a conditional section that ends with a corresponding \endcond command, which is typically found in another
comment block. The main purpose of this pair of commands is to (conditionally) exclude part of a file from processing
(in older version of doxygen this could only be achieved using C preprocessor commands).
The section between \cond and \endcond can be included by adding its section label to the ENABLED_SECTIONS
configuration option. If the section label is omitted, the section will be excluded from processing unconditionally. The
section label can be a logical expression build of section labels, round brackets, && (AND), || (OR) and ! (NOT). If
you use an expression you need to wrap it in round brackets, i.e \cond (!LABEL1 && LABEL2).
For conditional sections within a comment block one should use a \if ... \endif block. When using \cond and the
condition is not satisfied the current comment block is ended and everything until the matching \endcond is removed
and a new command block is started there.
Conditional sections can be nested. In this case a nested section will only be shown if it and its containing section
are included.
Here is an example showing the commands in action:
/** An interface */
class Intf
{
public:
/** A method */

virtual void func() = 0;
/// @cond TEST
/** A method used for testing */

virtual void test() = 0;
/// @endcond
};
/// @cond DEV

/*
* The implementation of the interface
*/
class Implementation : public Intf
{
public:
void func();
/// @cond TEST

void test();
/// @endcond
/// @cond
/** This method is obsolete and does
* not show up in the documentation.
*/
void obsolete();
/// @endcond
};
/// @endcond
The output will be different depending on whether or not ENABLED_SECTIONS contains TEST, or DEV
See also
sections \if, \ifnot, \else, \elseif, \endif, \endcond, and ENABLED_SECTIONS.
Note
Due to the moment of parsing the \cond and \endcond commands cannot be used in ALIASES.
24.68 \copyright { copyright description }

Starts a paragraph where the copyright of an entity can be described. This paragraph will be indented. The text of
the paragraph has no special internal structure. See section \author for an example.
24.69 \date { date description }

Starts a paragraph where one or more dates may be entered. The paragraph will be indented. The text of the
Multiple adjacent \date commands will be joined into a single paragraph. Each date description will start on a new
line. Alternatively, one \date command may mention several dates. The \date command ends when a blank
line or some other sectioning command is encountered. See section \author for an example.
24.70 \showdate ¨<format>¨ [ <date_time> ]

Shows the date and time based on the given <format> and <date_time>. Where the <format> is a string in
which the following tokens have a special meaning:
Code Description
%y Year without century as a zero-padded decimal number.
%Y Year with century as a decimal number.

24.70 \showdate ¨<format>¨ [ <date_time> ] 179
Code Description
%m Month as a zero-padded decimal number.
%-m The month as a decimal number.
%b Month as locale’s abbreviated name.
%B Month as locale’s full name.
%d Day of the month as a zero-padded decimal number.
%-d Day of the month as a decimal number.
%u The weekday as a decimal number (1-7), where Monday is 1.
%w The weekday as a decimal number (0-6), where Sunday is 0.
%a Weekday as locale’s abbreviated name.
%A Weekday as locale’s full name.
%H Hour (24-hour clock) as a zero-padded decimal number.

%-H Hour (24-hour clock) as a decimal number.
%I Hour (12-hour clock) as a zero-padded decimal number.
%-I Hour (12-hour clock) as a decimal number.
%M Minute as a zero-padded decimal number.
%-M Minute as a decimal number.
%S Second as a zero-padded decimal number.
%-S Second as a decimal number.
%p Locale’s equivalent of either AM or PM.
%% A % character.
Note that the <format> has to be between double quotes.

In case the <date_time> is specified it has to have the following representation:
• optional date where date is:
– 4 digits for the year

– a minus sign
– one or 2 digits for the month
– a minus sign
– one or 2 digits for the day
• optional time where time is:
– whitespace
– one or 2 digits for the hours
– a colon sign
– one or 2 digits for the minutes
– when the format contains %S or %-S
* a colon sign
* 2 digits for the seconds
in case the <date_time> is not specified the current date and time are used.
Here is an example:
- \showdate "%A %d-%m-%Y" 2015-3-14
- \showdate "%a %d-%m-%y" 2015-3-14
- \showdate "%-m.%d%y" 2015-3-14
- \showdate "%A %d-%m-%Y %H:%M:%S" 2015-3-14 03:04:15
- \showdate "%A %d-%m-%Y %H:%M" 2015-3-14 03:04
In case OUTPUT_LANGUAGE=english this results in:
• Saturday 14-03-2015
• Sat 14-03-15

• 3.1415
• Saturday 14-03-15 03:04:15
• Saturday 14-03-15 03:04
In case OUTPUT_LANGUAGE=dutch this results in:
• zaterdag 14-03-15
• za 14-03-2015
• 3.1415
• zaterdag 14-03-15 03:04:15
• zaterdag 14-03-15 03:04
24.71 \deprecated { description }

Starts a paragraph indicating that this documentation block belongs to a deprecated entity. Can be used to de-
scribe alternatives, expected life span, etc. The paragraph will be indented. The text of the paragraph has no
special internal structure. All visual enhancement commands may be used inside the paragraph. Multiple adjacent
\deprecated commands will be joined into a single paragraph. Each deprecation description will start on a new
line. The \deprecated command ends when a blank line or some other sectioning command is encountered.
The description will also add an item to a separate Deprecated list and the two instances of the description will be
cross-referenced. Each item in the Deprecated list will be preceded by a header that indicates the origin of the item.
The Deprecated list and the corresponding entries can be disabled by setting the GENERATE_DEPRECATEDLIST
to NO.
24.72 \details { detailed description }

Just like \brief starts a brief description, \details starts the detailed description. You can also start a new
paragraph (blank line) then the \details command is not needed.
24.73 \noop ( text to be ignored )

All the text, including the command, till the end of the line is ignored. The command will most commonly be used in
combination with ALIASES to ignore not supported commands that are present for e.g. other processing tools.
24.74 \raisewarning ( text to be shown as warning )

All the text, excluding the command, till the end of the line is literally shown as a documentation warning. The text,
including the command, is removed from the output. The command will most commonly be used in combination
with ALIASES to show a specific warning.
Example:
\raisewarning My specific warning
\warnNoDoc
\warnNoDoc{My specific warning}

together with:
ALIASES = warnNoDoc="\raisewarning Missing documentation"
ALIASES += warnNoDoc{1}="\raisewarning Incomplete documentation: \1"
will result in:

ex_1.md:1: warning: My specific warning
ex_1.md:3: warning: Missing documentation
ex_1.md:5: warning: Incomplete documentation: My specific warning

24.75 \else 181
24.75 \else
Starts a conditional section if the previous conditional section was not enabled. The previous section should have
been started with a \if, \ifnot, or \elseif command.
See also
sections \if, \ifnot, \elseif, \endif.
24.76 \elseif (section-label)

Starts a conditional documentation section if the previous section was not enabled. A conditional section is disabled
by default. To enable it you must put the section-label after the ENABLED_SECTIONS tag in the configuration
file. The section label can be a logical expression build of section names, round brackets, && (AND), || (OR) and !
(NOT). Conditional blocks can be nested. A nested section is only enabled if all enclosing sections are enabled as
well.
See also
sections \if, \ifnot, \else, \endif.
24.77 \endcond
Ends a conditional section that was started by \cond.
See also
section \cond.
Note
Due to the moment of parsing the \endcond and \cond commands cannot be used in ALIASES.
24.78 \endif
Ends a conditional section that was started by \if or \ifnot For each \if or \ifnot one and only one matching \endif must
follow.
See also
sections \if, \ifnot, \else, \elseif.
24.79 \exception <exception-object> { exception description }

Starts an exception description for an exception object with name <exception-object>. Followed by a description
of the exception. The existence of the exception object is not checked. The text of the paragraph has no spe-
cial internal structure. All visual enhancement commands may be used inside the paragraph. Multiple adjacent
\exception commands will be joined into a single paragraph. Each exception description will start on a new
line. The \exception description ends when a blank line or some other sectioning command is encountered.
See section \fn for an example.
24.80 \if (section-label)

Starts a conditional documentation section. The section ends with a matching \endif command. A conditional
section is disabled by default. To enable it you must put the section-label after the ENABLED_SECTIONS tag in the
configuration file.
The section label can be a logical expression build of section names, round brackets, && (AND), || (OR) and !
(NOT). If you use an expression you need to wrap it in round brackets, i.e \if (!LABEL1 && LABEL2).
Conditional blocks can be nested. A nested section is only enabled if all enclosing sections are enabled as well.
The \if and corresponding \endif have to be in the same comment block. When a conditional block needs to span
more than one comment block one has to use \cond ... \endcond.

Example:
/*! Unconditionally shown documentation.

* \if Cond1
* Only included if Cond1 is set.
* \endif
* \if Cond2
* Only included if Cond2 is set.
* \if Cond3
* Only included if Cond2 and Cond3 are set.
* \endif
* More text.
* \endif
* Unconditional text.
*/
You can also use conditional commands inside aliases. To document a class in two languages you could for instance
use:
Example 2:
/*! \english
* This is English.
* \endenglish
* \dutch
* Dit is Nederlands.
* \enddutch
*/
class Example
{
};
Where the following aliases are defined in the configuration file:
ALIASES = "english=\if english" \

"endenglish=\endif" \
"dutch=\if dutch" \
"enddutch=\endif"
and ENABLED_SECTIONS can be used to enable either english or dutch.
See also
sections \endif, \ifnot, \else, \elseif, \cond, \endcond, and ENABLED_SECTIONS.
24.81 \ifnot (section-label)

Starts a conditional documentation section. The section ends with a matching \endif command. This conditional
section is enabled by default. To disable it you must put the section-label after the ENABLED_SECTIONS tag in the
configuration file. The section label can be a logical expression build of section names, round brackets, && (AND),
|| (OR) and ! (NOT).
See also
sections \endif, \if, \else, and \elseif, \cond, \endcond, and ENABLED_SECTIONS.
24.82 \invariant { description of invariant }

Starts a paragraph where the invariant of an entity can be described. The paragraph will be indented. The text of the
Multiple adjacent \invariant commands will be joined into a single paragraph. Each invariant description will
start on a new line. Alternatively, one \invariant command may mention several invariants. The \invariant
command ends when a blank line or some other sectioning command is encountered.

24.83 \note { text } 183
24.83 \note { text }

Starts a paragraph where a note can be entered. The paragraph will be indented. The text of the paragraph has no
special internal structure. All visual enhancement commands may be used inside the paragraph. Multiple adjacent
\note commands will be joined into a single paragraph. Each note description will start on a new line. Alternatively,
one \note command may mention several notes. The \note command ends when a blank line or some other
sectioning command is encountered. See section \par for an example.
24.84 \par [(paragraph title)] { paragraph }

If a paragraph title is given this command starts a paragraph with a user defined heading. The heading extends until
the end of the line. The paragraph following the command will be indented.
If no paragraph title is given this command will start a new paragraph. This will also work inside other paragraph
commands (like \param or \warning) without ending that command.
The text of the paragraph has no special internal structure. All visual enhancement commands may be used inside
the paragraph. The \par command ends when a blank line or some other sectioning command is encountered.
Example:
/*! \class Par_Test

* Normal text.
*
* \par User defined paragraph:
* Contents of the paragraph.
*
* \par
* New paragraph under the same heading.
*
* \note
* This note consists of two paragraphs.
* This is the first paragraph.
*
* \par
* And this is the second paragraph.
*
* More normal text.
*/
class Par_Test {};
See Par example for the corresponding LATEX documentation that is generated by doxygen.
24.85 \param '['dir']' <parameter-name> { parameter description }

Starts a parameter description for a function parameter with name <parameter-name>, followed by a description
of the parameter. The existence of the parameter is checked and a warning is given if the documentation of this (or
any other) parameter is missing or not present in the function declaration or definition.
The \param command has an optional attribute, dir, specifying the direction of the parameter. Possible values
are ¨[in]¨, ¨[in,out]¨, and ¨[out]¨, note the [square] brackets in this description. When a parameter is both input and
output, [in,out] is used as attribute. Here is an example for the function memcpy:
/*!
Copies bytes from a source memory area to a destination memory area,
where both areas may not overlap.
@param[out] dest The memory area to copy to.
@param[in] src The memory area to copy from.
@param[in] n The number of bytes to copy
/
void memcpy(void *dest, const void *src, size_t n);
The parameter description is a paragraph with no special internal structure. All visual enhancement commands may
be used inside the paragraph.
Multiple adjacent \param commands will be joined into a single paragraph. Each parameter description will start
on a new line. The \param description ends when a blank line or some other sectioning command is encountered.
See section \fn for an example.
Note that you can also document multiple parameters with a single \param command using a comma separated
list. Here is an example:
/** Sets the position.
@param x,y,z Coordinates of the position in 3D space.
/
void setPosition(double x,double y,double z,double t)
{

}
Note that for PHP one can also specify the type (or types if you separate them with a pipe symbol) which are allowed
for a parameter (as this is not part of the definition). The syntax is the same as for the phpDocumentor, i.e.
@param datatype1|datatype2 $paramname description
24.86 \parblock
For commands that expect a single paragraph as argument (such as \par, \param and \warning), the \parblock
command allows to start a description that covers multiple paragraphs, which then ends with \endparblock.
Example:
/** Example of a param command with a description consisting of two paragraphs

* \param p
* \parblock
* First paragraph of the param description.
*
* Second paragraph of the param description.
* \endparblock
* Rest of the comment block continues.
*/
Note that the \parblock command may also appear directly after \param's first argument.
24.87 \endparblock
This ends a block of paragraphs started with \parblock.
24.88 \tparam <template-parameter-name> { description }

Starts a template parameter for a class or function template parameter with name <template-parameter-name>,
followed by a description of the template parameter.
Otherwise similar to \param.
24.89 \post { description of the postcondition }

Starts a paragraph where the postcondition of an entity can be described. The paragraph will be indented. The
paragraph. Multiple adjacent \post commands will be joined into a single paragraph. Each postcondition will start
on a new line. Alternatively, one \post command may mention several postconditions. The \post command
ends when a blank line or some other sectioning command is encountered.
24.90 \pre { description of the precondition }

Starts a paragraph where the precondition of an entity can be described. The paragraph will be indented. The
paragraph. Multiple adjacent \pre commands will be joined into a single paragraph. Each precondition will start
on a new line. Alternatively, one \pre command may mention several preconditions. The \pre command ends
when a blank line or some other sectioning command is encountered.
24.91 \remark { remark text }

Starts a paragraph where one or more remarks may be entered. The paragraph will be indented. The text of the
Multiple adjacent \remark commands will be joined into a single paragraph. Each remark will start on a new line.
Alternatively, one \remark command may mention several remarks. The \remark command ends when a blank
line or some other sectioning command is encountered.

24.92 \remarks { remark text } 185
24.92 \remarks { remark text }

Equivalent to \remark.
24.93 \result { description of the result value }

Equivalent to \return.
24.94 \return { description of the return value }

Starts a return value description for a function. The text of the paragraph has no special internal structure. All visual
enhancement commands may be used inside the paragraph. Multiple adjacent \return commands will be joined
into a single paragraph. The \return description ends when a blank line or some other sectioning command is
encountered. See section \fn for an example.
24.95 \returns { description of the return value }

Equivalent to \return.
24.96 \retval <return value> { description }

Starts a description for a function's return value with name <return value>, followed by a description of the return
value. The text of the paragraph that forms the description has no special internal structure. All visual enhancement
commands may be used inside the paragraph. Multiple adjacent \retval commands will be joined into a single
paragraph. Each return value description will start on a new line. The \retval description ends when a blank line
or some other sectioning command is encountered.
24.97 \sa { references }

Starts a paragraph where one or more cross-references to classes, functions, methods, variables, files or URL may
be specified. Two names joined by either :: or # are understood as referring to a class and one of its members.
One of several overloaded methods or constructors may be selected by including a parenthesized list of argument
types after the method name.
Synonymous to \see.
See also
section autolink for information on how to create links to objects.
24.98 \see { references }

Equivalent to \sa. Introduced for compatibility with Javadoc.
24.99 \short { short description }

Equivalent to \brief.
24.100 \since { text }

This command can be used to specify since when (version or time) an entity is available. The paragraph that follows
\since does not have any special internal structure. All visual enhancement commands may be used inside the
paragraph. The \since description ends when a blank line or some other sectioning command is encountered.

24.101 \test { paragraph describing a test case }

Starts a paragraph where one or more test cases can be described. The paragraph will be indented. The text of the
Multiple adjacent \test commands will be joined into a single paragraph. Each test case description will start on
a new line. Alternatively, one \test command may mention several test cases. The \test command ends when
a blank line or some other sectioning command is encountered.
The description will also add an item to a separate Test list and the two instances of the description will be cross-
referenced. Each item in the Test list will be preceded by a header that indicates the origin of the item.
The Test list and the corresponding entries can be disabled by setting the GENERATE_TESTLIST to NO.
24.102 \throw <exception-object> { exception description }

Synonymous \exception.
Note:
the command \throws is a synonym for this command.
See also
section \exception
24.103 \throws <exception-object> { exception description }

Equivalent to \throw.
24.104 \todo { paragraph describing what is to be done }

Starts a paragraph where one or more todo items are described. The paragraph will be indented. The text of the
Multiple adjacent \todo commands will be joined into a single paragraph. Each todo description will start on a
new line. Alternatively, one \todo command may mention several todo descriptions. The \todo command ends
when a blank line or some other sectioning command is encountered.
The description will also add an item to a separate Todo list and the two instances of the description will be cross-
referenced. Each item in the Todo list will be preceded by a header that indicates the origin of the item.
The Todo list and the corresponding entries can be disabled by setting the GENERATE_TODOLIST to NO.
24.105 \version { version number }

Starts a paragraph where one or more version strings may be entered. The paragraph will be indented. The
paragraph. Multiple adjacent \version commands will be joined into a single paragraph. Each version description
will start on a new line. Alternatively, one \version command may mention several version strings. The \version
command ends when a blank line or some other sectioning command is encountered. See section \author for an
example.
24.106 \warning { warning message }

Starts a paragraph where one or more warning messages may be entered. The paragraph will be indented. The
text of the paragraph has no special internal structure. All visual enhancement commands may be used inside
the paragraph. Multiple adjacent \warning commands will be joined into a single paragraph. Each warning
description will start on a new line. Alternatively, one \warning command may mention several warnings. The
\warning command ends when a blank line or some other sectioning command is encountered. See section
\author for an example.

24.107 \xrefitem <key> ¨heading¨ ¨list title¨ { text } 187
24.107 \xrefitem <key> ¨heading¨ ¨list title¨ { text }

This command is a generalization of commands such as \todo and \bug. It can be used to create user-defined text
sections which are automatically cross-referenced between the place of occurrence and a related page, which will
be generated. On the related page all sections of the same type will be collected.
The first argument <key> is an identifier uniquely representing the type of the section. The second argument is a
quoted string representing the heading of the section under which text passed as the fourth argument is put. The
third argument (list title) is used as the title for the related page containing all items with the same key. The second
and third string argument cannot contain a newline. The keys ¨todo¨, ¨test¨, ¨bug¨ and ¨deprecated¨
are predefined.
To get an idea on how to use the \xrefitem command and what its effect is, consider the todo list, which (for
English output) can be seen an alias for the command
\xrefitem todo "Todo" "Todo List"
Since it is very tedious and error-prone to repeat the first three parameters of the command for each section, the
command is meant to be used in combination with the ALIASES option in the configuration file. To define a new
command \reminder, for instance, one should add the following line to the configuration file:
ALIASES += "reminder=\xrefitem reminders \"Reminder\" \"Reminders\""
Note the use of escaped quotes for the second and third argument of the \xrefitem command.
In case parameter ¨(heading)¨ is the empty string no heading is generated. This can be useful when used in
combination with the \page command e.g.
/** @page my_errors My Errors
* @brief Errors page
*
* Errors page contents.
*/
/** \error ERROR 101: in case a file can not be opened.

Check about file system read/write access. */
#define MY_ERR_CANNOT_OPEN_FILE 101
/** \error ERROR 102: in case a file can not be closed.

Check about file system read/write access. */
#define MY_ERR_CANNOT_CLOSE_FILE 102
with \error defined as

ALIASES += "error=\xrefitem my_errors \"\" \"\""
Commands to create links

24.108 \addindex (text)
This command adds (text) to the LATEX , DocBook and RTF index.
24.109 \anchor <word>

This command places an invisible, named anchor into the documentation to which you can refer with the \ref com-
mand.
See also
section \ref.
24.110 \cite <label>

Adds a bibliographic reference in the text and in the list of bibliographic references. The <label> must be a valid
BibTeX label that can be found in one of the .bib files listed in CITE_BIB_FILES. For the LATEX output the formatting of
the reference in the text can be configured with LATEX_BIB_STYLE. For other output formats a fixed representation
is used. Note that using this command requires the bibtex tool to be present in the search path.

24.111 \endlink
This command ends a link that is started with the \link command.
See also
section \link.
24.112 \link <link-object>

The links that are automatically generated by doxygen always have the name of the object they point to as link-text.
The \link command can be used to create a link to an object (a file, class, or member) with a user specified link-
text. The link command should end with an \endlink command. All text between the \link and \endlink commands
serves as text for a link to the <link-object> specified as the first argument of \link.
See also
Section autolink for more information on automatically generated links and valid link-objects.
24.113 \ref <name> [¨(text)¨]

Creates a reference to a named symbol, file, section, subsection, page or anchor.
For HTML documentation the reference command will generate a link to the section. For a section or subsection the
title of the section will be used as the text of the link. For an anchor the optional text between quotes will be used or
<name> if no text is specified.
In case <name> has spaces (for instance if it refers a file name containing spaces) you need to add double quotes
around the <name>, e.g. ¨my file.md¨.
For LATEX documentation the reference command will be the same unless the PDF_HYPERLINKS option has been
set to NO, in this case it generates the section title for sections or the text if <name> refers to an anchor followed
by a page number.
See also
Section \page for an example of the \ref command.
24.114 \refitem <name>

Just like the \ref command, this command creates a reference to a named section, but this reference appears
in a list that is started by \secreflist and ends with \endsecreflist. An example of such a list can be seen
at the top of the page.
24.115 \secreflist
Starts an index list of item, created with \refitem that each link to a named section.
24.116 \endsecreflist
End an index list started with \secreflist.
24.117 \subpage <name> [¨(text)¨]

This command can be used to create a hierarchy of pages. The same structure can be made using the \defgroup
and \ingroup commands, but for pages the \subpage command is often more convenient. The main page (see
\mainpage) is typically the root of hierarchy.
This command behaves similar as \ref in the sense that it creates a reference to a page labeled <name> with the
optional link text as specified in the second argument.
It differs from the \ref command in that it only works for pages, and creates a parent-child relation between pages,
where the child page (or sub page) is identified by label <name>.
See the \section and \subsection commands if you want to add structure without creating multiple pages.

24.118 \tableofcontents['{'[option[:level]][,option[:level]]∗'}'] 189
Note
Each page can be the sub page of only one other page and no cyclic relations are allowed, i.e. the page
hierarchy must have a tree structure.
Here is an example:
/*! \mainpage A simple manual
Some general info.
This manual is divided in the following sections:

- \subpage intro
- \subpage advanced "Advanced usage"
*/
//-----------------------------------------------------------
/*! \page intro Introduction

This page introduces the user to the topic.
Now you can proceed to the \ref advanced "advanced section".
*/
//-----------------------------------------------------------
/*! \page advanced Advanced Usage

This page is for advanced users.
Make sure you have first read \ref intro "the introduction".
*/
24.118 \tableofcontents['{'[option[:level]][,option[:level]]∗'}']
Creates a table of contents at the top of a page, listing all sections and subsections in the page. The option can
be HTML or LaTeX or XML or DocBook. When a level is specified this means the maximum nesting level that
is shown. The value of level should be in the range 1..5, values outside this range are considered to be 5. In
case no level is specified level is set to 5 (show all) In case no option. is specified \tableofcontents
acts as if just the option HTML and XML was specified. In case of multiple \tableofcontents commands
in a page the option(s) will be used additional to the already specified option(s), but only the last level of an
option is valid.
Warning
This command only works inside related page documentation and not in other documentation blocks and only
has effect in the specified output!
24.119 \section <section-name> (section title)

Creates a section with name <section-name>. The title of the section should be specified as the second argument
of the \section command.
Warning
This command only works inside related page documentation and not in other documentation blocks!
See also
Section \page for an example of the \section command.
24.120 \subsection <subsection-name> (subsection title)

Creates a subsection with name <subsection-name>. The title of the subsection should be specified as the second
argument of the \subsection command.

Warning
This command only works inside a section of a related page documentation block and not in other documen-
tation blocks!
See also
Section \page for an example of the \subsection command.
24.121 \subsubsection <subsubsection-name> (subsubsection title)

Creates a subsubsection with name <subsubsection-name>. The title of the subsubsection should be specified as
the second argument of the \subsubsection command.
Warning
This command only works inside a subsection of a related page documentation block and not in other docu-
mentation blocks!
See also
Section \page for an example of the \section command and \subsection command.
24.122 \paragraph <paragraph-name> (paragraph title)

Creates a named paragraph with name <paragraph-name>. The title of the paragraph should be specified as the
second argument of the \paragraph command.
Warning
This command only works inside a subsubsection of a related page documentation block and not in other
documentation blocks!
Commands for displaying examples

24.123 \dontinclude['{lineno}'] <file-name>
This command can be used to parse a source file without actually verbatim including it in the documentation (as the
\include command does). This is useful if you want to divide the source file into smaller pieces and add documen-
tation between the pieces. Source files or directories can be specified using the EXAMPLE_PATH tag of doxygen's
configuration file.
You can add option {lineno} to enable line numbers for the included code if desired.
The class and member declarations and definitions inside the code fragment are 'remembered' during the parsing
of the comment block that contained the \dontinclude command.
For line by line descriptions of source files, one or more lines of the example can be displayed using the \line, \skip,
\skipline, and \until commands. An internal pointer is used for these commands. The \dontinclude command
sets the pointer to the first line of the example.
Example:
/*! A test class. */
class Include_Test
{
public:
/// a member function
void example();
};
/*! \page pag_example

* \dontinclude include_test.cpp
* Our main function starts like this:
* \skip main
* \until {

24.124 \include['{'option'}'] <file-name> 191
* First we create an object \c t of the Include_Test class.

* \skipline Include_Test
* Then we call the example member function
* \line example
* After that our little test routine ends.
* \line }
*/
Where the example file include_test.cpp looks as follows:

void main()
{
Include_Test t;
t.example();
}
See Include example for the corresponding LATEX documentation that is generated by doxygen.
See also
sections \line, \skip, \skipline, \until, and \include.
24.124 \include['{'option'}'] <file-name>

This command can be used to include a source file as a block of code. The command takes the name of an include
file as an argument. Source files or directories can be specified using the EXAMPLE_PATH tag of doxygen's
configuration file.
If <file-name> itself is not unique for the set of example files specified by the EXAMPLE_PATH tag, you can include
part of the absolute path to disambiguate it.
Using the \include command is equivalent to inserting the file into the documentation block and surrounding it
with \code and \endcode commands.
The main purpose of the \include command is to avoid code duplication in case of example blocks that consist
of multiple source and header files.
For a line by line description of a source files use the \dontinclude command in combination with the \line, \skip,
\skipline, and \until commands.
Alternatively, the \snippet command can be used to include only a fragment of a source file. For this to work the
fragment has to be marked.
Note
Doxygen's special commands do not work inside blocks of code. It is allowed to nest C-style comments inside
a code block though.
The option can either be lineno or doc. The option lineno can be used to enable line numbers for the
included code if desired. The option doc can be used to treat the file as documentation rather than code.
Note
When using the {doc} option, some commands like \cond and \if don't work with this command due to the
moment of parsing.
The included documentation should not have comment signs in it as they will appear in the documentation as
well.
See also
sections \example, \dontinclude, \verbatim, \includedoc, and \snippet.
24.125 \includelineno <file-name>

This command is obsolete and is still supported for backward compatibility reasons, it works the same way as
\include{lineno}
See also
sections \include{lineno}.

24.126 \includedoc <file-name>

\include{doc}
See also
section \include{doc}.
24.127 \line ( pattern )

This command searches line by line through the example that was last included using \include or \dontinclude until
it finds a non-blank line. If that line contains the specified pattern, it is written to the output.
The internal pointer that is used to keep track of the current line in the example, is set to the start of the line following
the non-blank line that was found (or to the end of the example if no such line could be found).
See section \dontinclude for an example.
24.128 \skip ( pattern )

it finds a line that contains the specified pattern.
The internal pointer that is used to keep track of the current line in the example, is set to the start of the line that
contains the specified pattern (or to the end of the example if the pattern could not be found).
24.129 \skipline ( pattern )

it finds a line that contains the specified pattern. It then writes the line to the output.
the line that is written (or to the end of the example if the pattern could not be found).
Note:
The command:
\skipline pattern
is equivalent to:
\skip pattern
\line pattern
24.130 \snippet['{'option'}'] <file-name> ( block_id )

Where the \include command can be used to include a complete file as source code, this command can be used to
quote only a fragment of a source file. In case this is used as <file-name> the current file is taken as file to take
the snippet from.
For example, the putting the following command in the documentation, references a snippet in file example.cpp
residing in a subdirectory which should be pointed to by EXAMPLE_PATH.
\snippet snippets/example.cpp Adding a resource
The text following the file name is the unique identifier for the snippet. This is used to delimit the quoted code in the
relevant snippet file as shown in the following example that corresponds to the above \snippet command:
QImage image(64, 64, QImage::Format_RGB32);
image.fill(qRgb(255, 160, 128));
//! [Adding a resource]

document->addResource(QTextDocument::ImageResource,
QUrl("mydata://image.png"), QVariant(image));

24.131 \snippetlineno <file-name> ( block_id ) 193
//! [Adding a resource]

...
Note that the lines containing the block markers will not be included, so the output will be:
document->addResource(QTextDocument::ImageResource,
QUrl("mydata://image.png"), QVariant(image));
Note also that the [block_id] markers should appear exactly twice in the source file.
• The option can either be lineno, trimleft or doc.
• The option lineno can be used to enable line numbers for the included code if desired.
• The option trimleft can be used to remove the common spacing in front of all lines (also taking in
account the setting of the TAB_SIZE tag).
• The option doc can be used to treat the file as documentation rather than code.
Note
When using the {doc} option, some commands like \cond and \if don't work with this command due to the
moment of parsing.
The included documentation should not have comment signs in it as they will appear in the documentation as
well.
see section \dontinclude for an alternative way to include fragments of a source file that does not require markers.
24.131 \snippetlineno <file-name> ( block_id )

\snippet{lineno}
See also
sections \snippet{lineno}
24.132 \snippetdoc <file-name> ( block_id )

\snippet{doc}
See also
section \snippet{doc} and \include{doc}.
24.133 \until ( pattern )

This command writes all lines of the example that was last included using \include or \dontinclude to the output, until
it finds a line containing the specified pattern. The line containing the pattern will be written as well.
last written line (or to the end of the example if the pattern could not be found).
24.134 \verbinclude <file-name>

This command includes the contents of the file <file-name> verbatim in the documentation. The command is equiv-
alent to pasting the contents of the file in the documentation and placing \verbatim and \endverbatim commands
around it.
Files or directories that doxygen should look for can be specified using the EXAMPLE_PATH tag of doxygen's
configuration file.

24.135 \htmlinclude [¨[block]¨] <file-name>

This command includes the contents of the file <file-name> as is in the HTML documentation and tagged with
<htmlonly> in the generated XML output. The command is equivalent to pasting the contents of the file in the
documentation and placing \htmlonly and \endhtmlonly commands around it.
Normally the contents of the file indicated by \htmlinclude is inserted as-is. When you want to insert a HTML
fragment that has block scope like a table or list which should appear outside <p>..</p>, this can lead to invalid
HTML. You can use \htmlinclude[block] to make doxygen end the current paragraph and restart after the file is
included.
configuration file.
See also
section \htmlonly, \latexinclude, \rtfinclude, \maninclude, \docbookinclude and \xmlinclude.
24.136 \latexinclude <file-name>

This command includes the contents of the file <file-name> as is in the LATEX documentation and tagged with
<latexonly> in the generated XML output. The command is equivalent to pasting the contents of the file in the
documentation and placing \latexonly and \endlatexonly commands around it.
configuration file.
See also
section \latexonly, \htmlinclude, \rtfinclude, \maninclude, \docbookinclude and \xmlinclude.
24.137 \rtfinclude <file-name>

This command includes the contents of the file <file-name> as is in the RTF documentation and tagged with
<rtfonly> in the generated XML output. The command is equivalent to pasting the contents of the file in the
documentation and placing \rtfonly and \endrtfonly commands around it.
configuration file.
See also
section \rtfonly, \htmlinclude, \latexinclude, \maninclude, \docbookinclude and \xmlinclude.
24.138 \maninclude <file-name>

This command includes the contents of the file <file-name> as is in the MAN documentation and tagged with
<manonly> in the generated XML output. The command is equivalent to pasting the contents of the file in the
documentation and placing \manonly and \endmanonly commands around it.
configuration file.
See also
section \manonly, \htmlinclude, \latexinclude, \rtfinclude, \docbookinclude and \xmlinclude.
24.139 \docbookinclude <file-name>

This command includes the contents of the file <file-name> as is in the DocBook documentation and tagged with
<docbookonly> in the generated XML output. The command is equivalent to pasting the contents of the file in
the documentation and placing \docbookonly and \enddocbookonly commands around it.
configuration file.

24.140 \xmlinclude <file-name> 195
See also
section \docbookonly, \htmlinclude, \latexinclude, \rtfinclude, \maninclude and \xmlinclude.
24.140 \xmlinclude <file-name>

This command includes contents of the file <file-name> as is in the XML documentation. The command is equiva-
lent to pasting the contents of the file in the documentation and placing \xmlonly and \endxmlonly commands around
it.
configuration file.
See also
section \xmlonly, \htmlinclude, \latexinclude, \rtfinclude, \maninclude and \docbookinclude.
Commands for visual enhancements
24.141 \a <word>
Displays the argument <word> in italics. Use this command to emphasize words. Use this command to refer to
member arguments in the running text.
Example:
... the \a x and \a y coordinates are used to ...

This will result in the following text:
... the x and y coordinates are used to ...
Equivalent to \e and \em. To emphasize multiple words use <em>multiple words</em>.
24.142 \arg { item-description }

This command has one argument that continues until the first blank line or until another \arg is encountered. The
command can be used to generate a simple, not nested list of arguments. Each argument should start with a \arg
command.
Example:
Typing:
\arg \c AlignLeft left alignment.
\arg \c AlignCenter center alignment.
\arg \c AlignRight right alignment
No other types of alignment are supported.
will result in the following text:
• AlignLeft left alignment.

• AlignCenter center alignment.
• AlignRight right alignment
Note:
For nested lists, HTML commands should be used.
Equivalent to \li

24.143 \b <word>
Displays the argument <word> using a bold font. Equivalent to <b>word</b>. To put multiple words in bold use
<b>multiple words</b>.
24.144 \c <word>
Displays the argument <word> using a typewriter font. Use this to refer to a word of code. Equivalent to
<tt>word</tt>.
Example:
Typing:
... This function returns \c void and not \c int ...
... This function returns void and not int ...
Equivalent to \p. To have multiple words in typewriter font use <tt>multiple words</tt>.
24.145 \code['{'<word>'}']
Starts a block of code. A code block is treated differently from ordinary text. It is interpreted as source code.
The names of classes and members and other documented entities are automatically replaced by links to the
documentation.
By default the language that is assumed for syntax highlighting is based on the location where the \code block
was found. If this part of a Python file for instance, the syntax highlight will be done according to the Python syntax.
If it is unclear from the context which language is meant (for instance the comment is in a .txt or .markdown
file) then you can also explicitly indicate the language, by putting the file extension typically that doxygen associated
with the language in curly brackets after the code block. Here is an example:
\code{.py}
class Python:
pass
\endcode
\code{.cpp}
class Cpp {};
\endcode
If the contents of the code block are in a language that doxygen cannot parse, doxygen will just show the output
as-is. You can make this explicit using .unparsed, or by giving some other extension that doxygen doesn't support,
e.g.
\code{.unparsed}
Show this as-is please
\endcode
\code{.sh}
echo "This is a shell script"
\endcode
See also
section \endcode and section \verbatim.
24.146 \copydoc <link-object>

Copies a documentation block from the object specified by <link-object> and pastes it at the location of the com-
mand. This command can be useful to avoid cases where a documentation block would otherwise have to be
duplicated or it can be used to extend the documentation of an inherited member.

24.147 \copybrief <link-object> 197
The link object can point to a member (of a class, file or group), a class, a namespace, a group, a page, or a
file (checked in that order). Note that if the object pointed to is a member (function, variable, typedef, etc), the
compound (class, file, or group) containing it should also be documented for the copying to work.
To copy the documentation for a member of a class one can, for instance, put the following in the documentation:
/*! @copydoc MyClass::myfunction()

* More documentation.
*/
if the member is overloaded, you should specify the argument types explicitly (without spaces!), like in the following:
//! @copydoc MyClass::myfunction(type1,type2)
Qualified names are only needed if the context in which the documentation block is found requires them.
The \copydoc command can be used recursively, but cycles in the \copydoc relation will be broken and flagged
as an error.
Note that \copydoc foo() is roughly equivalent to doing:
\brief \copybrief foo()

\details \copydetails foo()
See \copybrief and \copydetails for copying only the brief or detailed part of the comment block.
24.147 \copybrief <link-object>

Works in a similar way as \copydoc but will only copy the brief description, not the detailed documentation.
24.148 \copydetails <link-object>

Works in a similar way as \copydoc but will only copy the detailed documentation, not the brief description.
24.149 \docbookonly
Starts a block of text that only will be verbatim included in the generated DocBook documentation and tagged with
<docbookonly> in the generated XML output. The block ends with a \enddocbookonly command.
See also
section \manonly, \latexonly, \rtfonly, \xmlonly, \htmlonly and \docbookinclude.
24.150 \dot [¨caption¨] [<sizeindication>=<size>]

Starts a text fragment which should contain a valid description of a dot graph. The text fragment ends with \enddot.
Doxygen will pass the text on to dot and include the resulting image (and image map) into the output.
The first argument is optional and can be used to specify the caption that is displayed below the image. This
argument has to be specified between quotes even if it does not contain any spaces. The quotes are stripped
before the caption is displayed.
The second argument is also optional and can be used to specify the width or height of the image. For a description
of the possibilities see the paragraph Size indication with the \image command.
The nodes of a graph can be made clickable by using the URL attribute. By using the command \ref inside the URL
value you can conveniently link to an item inside doxygen. Here is an example:
Note
usage of this command requires that HAVE_DOT is set to YES

doxygen creates a temporary file that is automatically removed unless the DOT_CLEANUP tag is set to NO.
/*! class B */
class B {};
/*! class C */
class C {};

/*! \mainpage
Class relations expressed via an inline dot graph:

\dot
digraph example {
node [shape=record, fontname=Helvetica, fontsize=10];
b [ label="class B" URL="\ref B"];
c [ label="class C" URL="\ref C"];
b -> c [ arrowhead="open", style="dashed" ];
}
\enddot
Note that the classes in the above graph are clickable
(in the HTML output).
/
24.151 \emoji ¨name¨

This command will produce an emoji character given its name.
The supported names are the ones also supported by GitHub and listed here https://gist.github.←-
com/rxaviers/7360908
You can use the name with or without colons, i.e. \emoji smile is the same as writing \emoji :smile←-
:. When an emoji is not supported the name with by places in the text with in between colons, i.e. \emoji
unsupported will produce :unsupported: in the output. Doxygen will also give a warning message.
See also the emoji support page for details.
24.152 \msc [¨caption¨] [<sizeindication>=<size>]

Starts a text fragment which should contain a valid description of a message sequence chart. See https←-
://www.mcternan.me.uk/mscgen/ for examples. The text fragment ends with \endmsc.
The first argument is optional and can be used to specify the caption that is displayed below the image. This
argument has to be specified between quotes even if it does not contain any spaces. The quotes are stripped
before the caption is displayed.
The second argument is also optional and can be used to specify the width or height of the image. For a description
of the possibilities see the paragraph Size indication with the \image command.
Note
The text fragment should only include the part of the message sequence chart that is within the msc {...}
block (this is different from \mscfile).
mscgen is now built in into doxygen
Here is an example of the use of the \msc command.

/** Sender class. Can be used to send a command to the server.
The receiver will acknowledge the command by calling Ack().
\msc
Sender,Receiver;
Sender->Receiver [label="Command()", URL="\ref Receiver::Command()"];
Sender<-Receiver [label="Ack()", URL="\ref Ack()", ID="1"];
\endmsc
/
class Sender
{
public:
/** Acknowledgment from server */
void Ack(bool ok);
};
/** Receiver class. Can be used to receive and execute commands.

After execution of a command, the receiver will send an acknowledgment
\msc
Receiver,Sender;
Receiver<-Sender [label="Command()", URL="\ref Command()"];
Receiver->Sender [label="Ack()", URL="\ref Sender::Ack()", ID="1"];
\endmsc
/
class Receiver
{
public:
/** Executable a command on the server */
void Command(int commandId);
};

24.153 \startuml ['{'option[,option]'}'] [¨caption¨] [<sizeindication>=<size>] 199
See also
section \mscfile.
24.153 \startuml ['{'option[,option]'}'] [¨caption¨]

[<sizeindication>=<size>]
Starts a text fragment which should contain a valid description of a PlantUML diagram. See https←-
://plantuml.com/ for examples. The text fragment ends with \enduml.
Note
You need to install Java and the PlantUML's jar file, if you want to use this command. When using PlantUML
in LATEX you have to download some more jar files, for details see the PlantUML documentation. This also
is valid for the <engine>s latex and math. The location of the PlantUML file should be specified using
PLANTUML_JAR_PATH. The other jar files should also reside in this directory.
The use of the <engine> ditaa is not possible in LATEX as PlantUML only supports the png format and
doxygen requires, temporary, eps output.
Not all diagrams can be created with the PlantUML @startuml command but need another PlantUML
@start... command. This will look like @start<engine> where currently supported are the follow-
ing <engine>s: uml, bpm, wire, dot, ditaa, salt, math, latex, gantt, mindmap, wbs, yaml,
creole, json, flow, board, git, hcl, regex and ebnf. By default the <engine> is uml. The
<engine> can be specified as an option. Also the file to write the resulting image to can be specified by means
of an option, see the description of the first (optional) argument for details. Of course only one <engine> can be
specified and also the filename can only be specified once.
The first argument is optional and is for compatibility with running PlantUML as a preprocessing step before running
doxygen, you can also add the name of the image file after \startuml and inside curly brackets as option, i.e.
@startuml{myimage.png} "Image Caption" width=5cm

Alice -> Bob : Hello
@enduml
When the name of the image is specified, doxygen will generate an image with that name. Without the name
doxygen will choose a name automatically.
The second argument is optional and can be used to specify the caption that is displayed below the image. This
argument has to be specified between quotes even if it does not contain any spaces. The quotes are stripped before
the caption is displayed.
The third argument is also optional and can be used to specify the width or height of the image. For a description of
the possibilities see the paragraph Size indication with the \image command.
Note
doxygen does not support the Plantuml commands like @startjson, by design, directly but the support can
be accomplished, by the user, by adding to the doxygen settings file:
ALIASES += startjson=@startuml{json}
ALIASES += endjson=@enduml
Here is an example of the use of the \startuml command.

/** Sender class. Can be used to send a command to the server.
The receiver will acknowledge the command by calling Ack().
\startuml
Sender->Receiver : Command()
Sender<--Receiver : Ack()
\enduml
/
class Sender
{
public:
/** Acknowledgment from server */
void Ack(bool ok);
};
/** Receiver class. Can be used to receive and execute commands.

After execution of a command, the receiver will send an acknowledgment

\startuml
Receiver<-Sender : Command()
Receiver-->Sender : Ack()
\enduml
/
class Receiver
{
public:
/** Executable a command on the server */
void Command(int commandId);
};
24.154 \dotfile <file> [¨caption¨] [<sizeindication>=<size>]

Inserts an image generated by dot from <file> into the documentation.
The first argument specifies the file name of the image. doxygen will look for files in the paths (or files) that you
specified after the DOTFILE_DIRS tag. If the dot file is found it will be used as an input file to the dot tool. The
resulting image will be put into the correct output directory. If the dot file name contains spaces you'll have to put
quotes (¨...¨) around it.
Note
usage of this command requires that HAVE_DOT is set to YES
See also
section \dot.
24.155 \mscfile <file> [¨caption¨] [<sizeindication>=<size>]

Inserts an image generated by mscgen from <file> into the documentation. See https://www.←-
mcternan.me.uk/mscgen/ for examples.
specified after the MSCFILE_DIRS tag. If the msc file is found it will be used as an input file to the built in mscgen
tool. The resulting image will be put into the correct output directory. If the msc file name contains spaces you'll
have to put quotes (¨...¨) around it.
Note
The text fragment should include the part message of the sequence chart as well as the starting msc { and
ending } (this is different from \msc).
See also
section \msc.
24.156 \diafile <file> [¨caption¨] [<sizeindication>=<size>]

Inserts an image made in dia from <file> into the documentation.
specified after the DIAFILE_DIRS tag. If the dia file is found it will be used as an input file dia. The resulting image

24.157 \doxyconfig <config_option> 201
will be put into the correct output directory. If the dia file name contains spaces you'll have to put quotes (¨...¨) around
it.
24.157 \doxyconfig <config_option>

Displays the value of the configuration option <config_option> as used in doxygen's configuration file that is
in use when this command is processed.
Example:
When creating this manual the following:
... Project name = \doxyconfig PROJECT_NAME ...
gives:
... Project name = Doxygen ...
24.158 \e <word>
Displays the argument <word> in italics. Use this command to emphasize words.
Example:
Typing:
... this is a \e really good example ...
... this is a really good example ...
Equivalent to \a and \em. To emphasize multiple words use <em>multiple words</em>.
24.159 \em <word>

Displays the argument <word> in italics. Use this command to emphasize words.
Example:
Typing:
... this is a \em really good example ...
... this is a really good example ...
Equivalent to \a and \e. To emphasize multiple words use <em>multiple words</em>.
24.160 \endcode
Ends a block of code.
See also
section \code

24.161 \enddocbookonly
Ends a block of text that was started with a \docbookonly command.
See also
section \docbookonly.
24.162 \enddot
Ends a block that was started with \dot.
24.163 \endmsc
Ends a block that was started with \msc.
24.164 \enduml
Ends a block that was started with \startuml.
24.165 \endhtmlonly
Ends a block of text that was started with a \htmlonly command.
See also
section \htmlonly.
24.166 \endlatexonly
Ends a block of text that was started with a \latexonly command.
See also
section \latexonly.
24.167 \endmanonly
Ends a block of text that was started with a \manonly command.
See also
section \manonly.
24.168 \endrtfonly
Ends a block of text that was started with a \rtfonly command.
See also
section \rtfonly.
24.169 \endverbatim
Ends a block of text that was started with a \verbatim command.
See also
section \verbatim.

24.170 \endxmlonly 203
24.170 \endxmlonly
Ends a block of text that was started with a \xmlonly command.
See also
section \xmlonly.
24.171 \f$
Marks the start and end of an in-text formula.
See also
section formulas for an example.
24.172 \f(
Marks the start of an in-text formula, but contrary to \f$ it will not explicitly open the math-mode in LATEX.
See also
section \f) and section formulas.
24.173 \f)
Marks the end of an in-text formula started with \f(.
See also
section \f( and section formulas.
24.174 \f[
Marks the start of a long formula that is displayed centered on a separate line.
See also
section \f] and section formulas.
24.175 \f]
Marks the end of a long formula that is displayed centered on a separate line.
See also
section \f[ and section formulas.
24.176 \f{environment}{
Marks the start of a formula that is in a specific environment.
Note
The second { is optional and is only to help editors (such as Vim) to do proper syntax highlighting by making
the number of opening and closing braces the same.
See also
section \f} and section formulas.

24.177 \f}
Marks the end of a formula that is in a specific environment.
See also
section \f{ and section formulas.
24.178 \htmlonly [¨[block]¨]

Starts a block of text that only will be verbatim included in the generated HTML documentation and tagged with
<htmlonly> in the generated XML output. The block ends with a \endhtmlonly command.
This command can be used to include HTML code that is too complex for doxygen (i.e. applets, java-scripts, and
HTML tags that require specific attributes).
Normally the contents between \htmlonly and \endhtmlonly is inserted as-is. When you want to insert a HTML
fragment that has block scope like a table or list which should appear outside <p>..</p>, this can lead to invalid
HTML. You can use \htmlonly[block] to make doxygen end the current paragraph and restart it after \endhtmlonly.
Note
environment variables (like $(HOME) ) are resolved inside a HTML-only block.
See also
section \manonly, \latexonly, \rtfonly, \xmlonly, \docbookonly, and \htmlinclude.
24.179 \image['{'option[,option]'}'] <format> <file> [¨caption¨]

[<sizeindication>=<size>]
Inserts an image into the documentation. This command is format specific, so if you want to insert an image for
more than one format you'll have to repeat this command for each format.
The first argument specifies the output format in which the image should be embedded. Currently, the following
values are supported: html, latex, docbook, rtf and xml.
The second argument specifies the file name of the image. doxygen will look for files in the paths (or files) that you
specified after the IMAGE_PATH tag. If the image is found it will be copied to the correct output directory. If the
image name contains spaces you'll have to put quotes (¨...¨) around the name. You can also specify an absolute
URL instead of a file name, but then doxygen does not copy the image nor check its existence.
The third argument is optional and can be used to specify the caption that is displayed below the image. This
argument has to be specified on a single line and between quotes even if it does not contain any spaces. The
quotes are stripped before the caption is displayed.
The fourth argument is also optional and can be used to specify the width or height of the image. This can be useful
for LATEX or DocBook output (i.e. format=latex or format=docbook).
Size indication
The sizeindication can specify the width or height to be used (or a combination). The size specifier in
LATEX (for example 10cm or 4in or a symbolic width like \textwidth).
Currently only the options inline and anchor are supported. In case the option inline is specified the image
is placed ïn the line¨, when a caption is present it is shown in HTML as tooltip (ignored for the other formats). For
the anchor option the syntax is: anchor:<anchorId>.
Here is example of a comment block:
/*! Here is a snapshot of my new application:

* \image html application.jpg
* \image latex application.eps "My application" width=10cm
*/
And this is an example of how the relevant part of the configuration file may look:
IMAGE_PATH = my_image_dir

24.180 \latexonly 205
Warning
The image format for HTML is limited to what your browser supports.
For LATEX, the image format must be supported by the LATEX \includegraphics command i.e. Encapsu-
lated PostScript (eps), Portable network graphics (png), Joint photographic experts group (jpg / jpeg).
Doxygen does not check if the image is in the correct format. So you have to make sure this is the
case!
24.180 \latexonly
Starts a block of text that only will be verbatim included in the generated LATEX documentation and tagged with
<latexonly> in the generated XML output. The block ends with a \endlatexonly command.
This command can be used to include LATEX code that is too complex for doxygen (i.e. images, formulas, special
characters). You can use the \htmlonly and \endhtmlonly pair to provide a proper HTML alternative.
Note: environment variables (like $(HOME) ) are resolved inside a LATEX-only block.
See also
sections \rtfonly, \xmlonly, \manonly, \htmlonly, \docbookonly, and \latexinclude.
24.181 \manonly
Starts a block of text that only will be verbatim included in the generated MAN documentation and tagged with
<manonly> in the generated XML output. The block ends with a \endmanonly command.
This command can be used to include groff code directly into MAN pages. You can use the \htmlonly and
\endhtmlonly and \latexonly and \endlatexonly pairs to provide proper HTML and LATEX alternatives.
See also
sections \htmlonly, \xmlonly, \rtfonly, \latexonly, \docbookonly and \maninclude.
24.182 \li { item-description }

This command has one argument that continues until the first blank line or until another \li is encountered. The
command can be used to generate a simple, not nested list of arguments. Each argument should start with a \li
command.
Example:
Typing:
\li \c AlignLeft left alignment.
\li \c AlignCenter center alignment.
\li \c AlignRight right alignment
• AlignLeft left alignment.

• AlignCenter center alignment.
• AlignRight right alignment
Note:
For nested lists, HTML commands should be used.
Equivalent to \arg

24.183 \n
Forces a new line. Equivalent to <br> and inspired by the printf function.
24.184 \p <word>
Displays the parameter <word> using a typewriter font. You can use this command to refer to member function
parameters in the running text.
Example:
... the \p x and \p y coordinates are used to ...
This will result in the following text:
... the x and y coordinates are used to ...
Equivalent to \c. To have multiple words in typewriter font use <tt>multiple words</tt>.
24.185 \rtfonly
Starts a block of text that only will be verbatim included in the generated RTF documentation and tagged with
<rtfonly> in the generated XML output. The block ends with a \endrtfonly command.
This command can be used to include RTF code that is too complex for doxygen.
Note: environment variables (like $(HOME) ) are resolved inside a RTF-only block.
See also
sections \manonly, \xmlonly, \latexonly, \htmlonly, \docbookonly and \rtfinclude.
24.186 \verbatim
Starts a block of text that will be verbatim included in the documentation. The block should end with a \endverbatim
command. All commands are disabled in a verbatim block.
Warning
Make sure you include a \endverbatim command for each \verbatim command or the parser will get
confused!
See also
sections \code, \endverbatim and \verbinclude.
24.187 \xmlonly
Starts a block of text that only will be verbatim included in the generated XML output. The block ends with a
\endxmlonly command.
This command can be used to include custom XML tags.
See also
sections \manonly, \rtfonly, \latexonly, \htmlonly, and \docbookonly.
24.188 \\
This command writes a backslash character (\) to the output. The backslash has to be escaped in some cases
because doxygen uses it to detect commands.

24.189 \@ 207
24.189 \@
This command writes an at-sign (@) to the output. The at-sign has to be escaped in some cases because doxygen
uses it to detect Javadoc commands.
24.190 \∼[LanguageId]
This command enables/disables a language specific filter. This can be used to put documentation for different
language into one comment block and use the OUTPUT_LANGUAGE tag to filter out only a specific language. Use
\∼language_id to enable output for a specific language only and \∼ to enable output for all languages (this is
also the default mode).
Example:
/*! \~english This is English \~dutch Dit is Nederlands \~german Dies ist
Deutsch. \~ output for all languages.
*/
24.191 \&
This command writes the & character to the output. This character has to be escaped because it has a special
meaning in HTML.
24.192 \$
This command writes the $ character to the output. This character has to be escaped in some cases, because it is
used to expand environment variables.
24.193 \#
This command writes the # character to the output. This character has to be escaped in some cases, because it is
used to refer to documented entities.
24.194 \<
This command writes the < character to the output. This character has to be escaped because it has a special
meaning in HTML.
24.195 \>
This command writes the > character to the output. This character has to be escaped because it has a special
meaning in HTML.
24.196 \%
This command writes the % character to the output. This character has to be escaped in some cases, because it is
used to prevent auto-linking to a word that is also a documented class or struct.
24.197 \¨
This command writes the " character to the output. This character has to be escaped in some cases, because it is
used in pairs to indicate an unformatted text fragment.
24.198 \.
This command writes a dot (.) to the output. This can be useful to prevent ending a brief description when
JAVADOC_AUTOBRIEF is enabled or to prevent starting a numbered list when the dot follows a number at the start
of a line.

24.199 \=
This command writes an equal sign (=) to the output. This character sequence has to be escaped in some cases,
because it is used in Markdown header processing.
24.200 \::
This command writes a double colon (::) to the output. This character sequence has to be escaped in some cases,
because it is used to reference to documented entities.
24.201 \|
This command writes a pipe symbol (|) to the output. This character has to be escaped in some cases, because it
is used for Markdown tables.
24.202 \–
This command writes two dashes (--) to the output. This allows writing two consecutive dashes to the output instead
of one n-dash character (–).
24.203 \—
This command writes three dashes (---) to the output. This allows writing three consecutive dashes to the output
instead of one m-dash character (—).

Chapter 25
HTML Commands
25.1 HTML tag commands

Here is a list of all HTML commands that may be used inside the documentation. Note that although these HTML
tags are translated to the proper commands for output formats other than HTML, all attributes of a HTML tag are
passed on to the HTML output only (the HREF and NAME attributes for the A tag are the only exception).
HTML Command Description

<A HREF=¨...¨> Starts a hyperlink (if supported by the output format).
<A ID=¨...¨> Starts a named anchor (if supported by the output format).
<A NAME=¨...¨> Starts a named anchor (if supported by the output format).
</A> Ends a link or anchor
<B> / </B> Starts and ends a piece of text displayed in a bold font.
<BLOCKQUOTE> / </BLOCKQUOTE> Starts and ends a quotation block.
<BR> Forces a line break.
<CENTER> / </CENTER> Starts and ends a section of centered text.
<CAPTION> / </CAPTION> Starts and ends a caption. Use within a table only.
<CITE> / </CITE> Starts and ends a section of text displayed in a font specific for
citations.
<CODE> / </CODE> Starts and ends a piece of text displayed in a typewriter font. Note
that only for C# code, this command is equivalent to \code (see
<code>).
<DD> / </DD> Starts and ends an item description.
<DEL> / </DEL> Starts and ends a section of deleted text, typically shown as strike
through text.
<DETAILS> / </DETAILS> Starts and ends a section of detailed text that the user can open
and close (in HTML output))
<DFN> / </DFN> Starts and ends a piece of text displayed in a typewriter font.
<DIV> / </DIV> Starts and ends a section with a specific style (HTML only)
<DL> / </DL> Starts and ends a description list.
<DT> / </DT> Starts and ends an item title.
<EM> / </EM> Starts and ends a piece of text displayed in an italic font.
<HR> Writes a horizontal ruler.
<H1> / </H1> Starts and ends an unnumbered section.
<H2> / </H2> Starts and ends an unnumbered subsection.
<H3> / </H3> Starts and ends an unnumbered subsubsection.
<I> / </I> Starts and ends a piece of text displayed in an italic font.

210 HTML Commands
HTML Command Description

<IMG SRC=¨...¨ ...> This command is written with its attributes to the HTML output only.
The SRC attribute is mandatory.
<INS> / </INS> Starts and ends a section of inserted text, typically shown as un-
derlined text.
<KBD> / </KBD> Starts and ends a piece of text displayed in a typewriter font.
<LI> / </LI> Starts and ends a new list item.
<OL> / </OL> Starts and ends a numbered item list.
<P> / </P> Starts and ends a new paragraph.
<PRE> / </PRE> Starts and ends a preformatted fragment.
<S> / </S> Starts and ends a section of strike through text.
<SMALL> / </SMALL> Starts and ends a section of text displayed in a smaller font.
<SPAN> / </SPAN> Starts and ends an inline text fragment with a specific style (HTML
only)
<STRIKE> / </STRIKE> Starts and ends a section of strike through text.
<STRONG> / </STRONG> Starts and ends a section of bold text.
<SUB> / </SUB> Starts and ends a piece of text displayed in subscript.
<SUP> / </SUP> Starts and ends a piece of text displayed in superscript.
<TABLE> / </TABLE> Starts and ends a table.
<TBODY> / </TBODY> Starts and ends a new table body, currently ignored by doxygen.
<TD> / </TD> Starts and ends a new table data element.
<TH> / </TH> Starts and ends a new table header.
<THEAD> / </THEAD> Starts and ends a new table header, currently ignored by doxygen.
<TFOOT> / </TFOOT> Starts and ends a new table footer, currently ignored by doxygen.
<TR> / </TR> Starts and ends a new table row.
<TT> / </TT> Starts and ends a piece of text displayed in a typewriter font.
<U> / </U> Starts and ends a section of underlined text.
<UL> / </UL> Starts and ends an unnumbered item list.
<VAR> / </VAR> Starts and ends a piece of text displayed in an italic font.
Finally, to put invisible comments inside comment blocks, HTML style comments can be used:
/*!  Visible text */
The part  will not be shown in the main documentation.
25.2 HTML4 character entities

The list of special HTML4 character entities with their descriptions has been taken from: Character entity
references in HTML 4. ( Portions © International Organization for Standardization 1986 Permission to copy
in any form is granted for use with conforming SGML systems and applications as defined in ISO 8879, provided
this notice is included in all copies.)
Entity Description
no-break space = non-breaking space
¡ ¡ inverted exclamation mark
¢ ¢ cent sign
£ £ pound sign
¤ ¤ currency sign
¥ ¥ yen sign = yuan sign
¦ ¦ broken bar = broken vertical bar
§ § section sign
¨ ¨ diaeresis = spacing diaeresis

25.2 HTML4 character entities 211
Entity Description
© © copyright sign
ª ª feminine ordinal indicator
« « left-pointing double angle quotation mark = left pointing guillemet
¬ ¬ not sign
soft hyphen = discretionary hyphen
® ® registered sign = registered trade mark sign
¯ ¯ macron = spacing macron = overline = APL overbar
° ° degree sign
± ± plus-minus sign = plus-or-minus sign
² ² superscript two = superscript digit two = squared
³ ³ superscript three = superscript digit three = cubed
´ ´ acute accent = spacing acute
µ µ micro sign
¶ ¶ pilcrow sign = paragraph sign
· · middle dot = Georgian comma = Greek middle dot
¸ ¸ cedilla = spacing cedilla
¹ ¹ superscript one = superscript digit one
º º masculine ordinal indicator
» » right-pointing double angle quotation mark = right pointing guillemet
1
¼ 4 vulgar fraction one quarter = fraction one quarter
1
½ 2 vulgar fraction one half = fraction one half
3
¾ 4 vulgar fraction three quarters = fraction three quarters
¿ ¿ inverted question mark = turned question mark
À À latin capital letter A with grave = latin capital letter A grave
Á Á latin capital letter A with acute
Â Â latin capital letter A with circumflex
Ã Ã latin capital letter A with tilde
Ä Ä latin capital letter A with diaeresis
Å Å latin capital letter A with ring above = latin capital letter A ring
Æ Æ latin capital letter AE = latin capital ligature AE
Ç Ç latin capital letter C with cedilla
È È latin capital letter E with grave
É É latin capital letter E with acute
Ê Ê latin capital letter E with circumflex
Ë Ë latin capital letter E with diaeresis
Ì Ì latin capital letter I with grave
Í Í latin capital letter I with acute
Î Î latin capital letter I with circumflex
Ï Ï latin capital letter I with diaeresis
Ð Ð latin capital letter ETH
Ñ Ñ latin capital letter N with tilde
Ò Ò latin capital letter O with grave
Ó Ó latin capital letter O with acute
Ô Ô latin capital letter O with circumflex
Õ Õ latin capital letter O with tilde

212 HTML Commands
Entity Description
Ö Ö latin capital letter O with diaeresis
× × multiplication sign
Ø Ø latin capital letter O with stroke = latin capital letter O slash
Ù Ù latin capital letter U with grave
Ú Ú latin capital letter U with acute
Û Û latin capital letter U with circumflex
Ü Ü latin capital letter U with diaeresis
Ý Ý latin capital letter Y with acute
Þ Þ latin capital letter THORN
ß ß latin small letter sharp s = ess-zed
à à latin small letter a with grave = latin small letter a grave
á á latin small letter a with acute
â â latin small letter a with circumflex
ã ã latin small letter a with tilde
ä ä latin small letter a with diaeresis
å å latin small letter a with ring above = latin small letter a ring
æ æ latin small letter ae = latin small ligature ae
ç ç latin small letter c with cedilla
è è latin small letter e with grave
é é latin small letter e with acute
ê ê latin small letter e with circumflex
ë ë latin small letter e with diaeresis
ì ì latin small letter i with grave
í í latin small letter i with acute
î î latin small letter i with circumflex
ï ï latin small letter i with diaeresis
ð ð latin small letter eth
ñ ñ latin small letter n with tilde
ò ò latin small letter o with grave
ó ó latin small letter o with acute
ô ô latin small letter o with circumflex
õ õ latin small letter o with tilde
ö ö latin small letter o with diaeresis
÷ ÷ division sign
ø ø latin small letter o with stroke, = latin small letter o slash
ù ù latin small letter u with grave
ú ú latin small letter u with acute
û û latin small letter u with circumflex
ü ü latin small letter u with diaeresis
ý ý latin small letter y with acute
þ þ latin small letter thorn
ÿ ÿ latin small letter y with diaeresis
&fnof; ƒ latin small f with hook = function = florin
Α A greek capital letter alpha
Β B greek capital letter beta
Γ Γ greek capital letter gamma
Δ ∆ greek capital letter delta
Ε E greek capital letter epsilon
Ζ Z greek capital letter zeta

Entity Description
Η H greek capital letter eta
Θ Θ greek capital letter theta
Ι I greek capital letter iota
Κ K greek capital letter kappa
Λ Λ greek capital letter lambda
Μ M greek capital letter mu
Ν N greek capital letter nu
Ξ Ξ greek capital letter xi
Ο O greek capital letter omicron
Π Π greek capital letter pi
Ρ P greek capital letter rho
Σ Σ greek capital letter sigma
Τ T greek capital letter tau
Υ ϒ greek capital letter upsilon
Φ Φ greek capital letter phi
Χ X greek capital letter chi
Ψ Ψ greek capital letter psi
Ω Ω greek capital letter omega
α α greek small letter alpha
β β greek small letter beta
γ γ greek small letter gamma
δ δ greek small letter delta
ε ε greek small letter epsilon
ζ ζ greek small letter zeta
η η greek small letter eta
θ θ greek small letter theta
ι ι greek small letter iota
κ κ greek small letter kappa
λ λ greek small letter lambda
μ µ greek small letter mu
ν ν greek small letter nu
ξ ξ greek small letter xi
ο o greek small letter omicron
π π greek small letter pi
ρ ρ greek small letter rho
&sigmaf; ς greek small letter final sigma
σ σ greek small letter sigma
τ τ greek small letter tau
υ υ greek small letter upsilon
φ ϕ greek small letter phi
χ χ greek small letter chi
ψ ψ greek small letter psi
ω ω greek small letter omega
&thetasym; ϑ greek small letter theta symbol
&upsih; ϒ greek upsilon with hook symbol
ϖ ϖ greek pi symbol
• • bullet = black small circle
… ... horizontal ellipsis = three dot leader

214 HTML Commands
Entity Description
′ ’ prime = minutes = feet
″ ” double prime = seconds = inches
&oline; overline = spacing overscore
&frasl; / fraction slash
&weierp; ℘ script capital P = power set = Weierstrass p
&image; ℑ blackletter capital I = imaginary part
&real; ℜ blackletter capital R = real part symbol
™ ™ trade mark sign
&alefsym; ℵ alef symbol = first transfinite cardinal
← ← leftwards arrow
↑ ↑ upwards arrow
→ → rightwards arrow
↓ ↓ downwards arrow
↔ ↔ left right arrow
&crarr; ←- downwards arrow with corner leftwards = carriage return
⇐ ⇐ leftwards double arrow
&uArr; ⇑ upwards double arrow
⇒ ⇒ rightwards double arrow
&dArr; ⇓ downwards double arrow
⇔ ⇔ left right double arrow
∀ ∀ for all
∂ ∂ partial differential
∃ ∃ there exists
∅ 0/ empty set = null set = diameter
∇ ∇ nabla = backward difference
∈ ∈ element of
∉ ∈/ not an element of
&ni; ∋ contains as member
∏ ∏ n-ary product = product sign
∑ ∑ n-ary summation
− - minus sign
&lowast; ∗ asterisk operator
√
√ square root = radical sign
&prop; ∝ proportional to
∞ ∞ infinity
&ang; ∠ angle
&and; ∧ logical and = wedge
&or; ∨ logical or = vee
∩ ∩ intersection = cap
∪ ∪ union = cup
R
∫ integral
&there4; ∴ therefore
&sim; ∼ tilde operator = varies with = similar to
&cong; ∼
= approximately equal to
≈ ≈ almost equal to = asymptotic to
≠ ̸ = not equal to
&equiv; ≡ identical to
≤ ≤ less-than or equal to

Entity Description
≥ ≥ greater-than or equal to
⊂ ⊂ subset of
⊃ ⊃ superset of
&nsub; ̸ ⊂ not a subset of
&sube; ⊆ subset of or equal to
&supe; ⊇ superset of or equal to
&oplus; ⊕ circled plus = direct sum
&otimes; ⊗ circled times = vector product
&perp; ⊥ up tack = orthogonal to = perpendicular
⋅ · dot operator
&lceil; ⌈ left ceiling = apl upstile
&rceil; ⌉ right ceiling
&lfloor; ⌊ left floor = apl downstile
&rfloor; ⌋ right floor
&lang; ⟨ left-pointing angle bracket = bra
&rang; ⟩ right-pointing angle bracket = ket
&loz; ♢ lozenge
&spades; ♠ black spade suit
&clubs; ♣ black club suit = shamrock
&hearts; ♡ black heart suit = valentine
&diams; ♢ black diamond suit
" " quotation mark = APL quote
& & ampersand
< < less-than sign
> > greater-than sign
&OElig; Œ latin capital ligature OE
&oelig; œ latin small ligature oe
&Scaron; Š latin capital letter S with caron
&scaron; š latin small letter s with caron
&Yuml; Ÿ latin capital letter Y with diaeresis
&circ; ◦ modifier letter circumflex accent
&tilde; ˜ small tilde
&ensp; en space
&emsp; em space
thin space
&zwnj; zero width non-joiner
&zwj; zero width joiner
&lrm; left-to-right mark
&rlm; right-to-left mark
– – en dash
— — em dash
‘ ‘ left single quotation mark
’ ’ right single quotation mark
&sbquo; ‚ single low-9 quotation mark
“ “ left double quotation mark
” ” right double quotation mark
&bdquo; „ double low-9 quotation mark
&dagger; † dagger

216 HTML Commands
Entity Description
&Dagger; ‡ double dagger
&permil; h per mille sign
&lsaquo; ‹ single left-pointing angle quotation mark
&rsaquo; › single right-pointing angle quotation mark
€ C euro sign
Doxygen extensions:
&tm; ™ trade mark sign
' ' apostrophe

Chapter 26
XML Commands
Doxygen supports most of the XML commands that are typically used in C# code comments. The XML tags are
defined in Appendix D of the ECMA-334 standard, which defines the C# language. Unfortunately, the specification
is not very precise and a number of the examples given are of poor quality.
Here is the list of tags supported by doxygen:
XML Command Description

<c> Identifies inline text that should be rendered as a piece of
code. Similar to using <tt>text</tt>.
<code> Set one or more lines of source code or program output.
Note that this command behaves like \code ... \endcode
for C# code, but it behaves like the HTML equivalent
<CODE>...</CODE> for other languages.
<description> Part of a <list> command, describes an item.
<example> Marks a block of text as an example, ignored by doxygen.
<exception cref=¨member¨> Identifies the exception a method can throw.
<include> Can be used to import a piece of XML from an external file.
Ignored by doxygen at the moment.
<inheritdoc> Can be used to insert the documentation of a member of a
base class into the documentation of a member of a derived
class that reimplements it.
<item> List item. Can only be used inside a <list> context.
<list type=¨type¨> Starts a list, supported types are bullet or number and
table. A list consists of a number of <item> tags. A list
of type table, is a two column table which can have a header.
<listheader> Starts the header of a list of type ¨table¨.
<para> Identifies a paragraph of text.
<param name=¨paramName¨> Marks a piece of text as the documentation for parameter
¨paramName¨. Similar to using \param.
<paramref name=¨paramName¨> Refers to a parameter with name ¨paramName¨. Similar to
using \a.
<permission> Identifies the security accessibility of a member. Ignored by
doxygen.
<remarks> Identifies the detailed description.
<returns> Marks a piece of text as the return value of a function or
method. Similar to using \return.
<see cref=¨member¨> Refers to a member. Similar to \ref.
<seealso cref=¨member¨> Starts a ¨See also¨ section referring to ¨member¨. Similar to
using \sa member.

218 XML Commands
XML Command Description

<summary> In case this tag is used outside a <DETAILS> tag this tag
identifies the brief description. Similar to using \brief. In case
this tag is used inside a <DETAILS> tag this tag identifies
the heading of the <DETAILS> tag.
<term> Part of a <list> command.
<typeparam name=¨paramName¨> Marks a piece of text as the documentation for type parame-
ter ¨paramName¨. Similar to using \param.
<typeparamref name=¨paramName¨> Refers to a parameter with name ¨paramName¨. Similar to
using \a.
<value> Identifies a property. Ignored by doxygen.
<![CDATA[...]]> The text inside this tag (on the ...) is handled as normal doxy-
gen comment except for the XML special characters <, >
and & that are used as if they were escaped.
Here is an example of a typical piece of code using some of the above commands:
/// <summary>
/// A search engine.
/// </summary>
class Engine
{
/// <summary>
/// The Search method takes a series of parameters to specify the search criterion
/// and returns a dataset containing the result set.
/// </summary>
/// <param name="connectionString">the connection string to connect to the
/// database holding the content to search</param>
/// <param name="maxRows">The maximum number of rows to
/// return in the result set</param>
/// <param name="searchString">The text that we are searching for</param>
/// <returns>A DataSet instance containing the matching rows. It contains a maximum
/// number of rows specified by the maxRows parameter</returns>
public DataSet Search(string connectionString, int maxRows, int searchString)
{
DataSet ds = new DataSet();
return ds;
}
}

Chapter 27
Emoji support
The Unicode consortium has defined a set of emoji with the corresponding unicode sequences. Doxy-
gen supports the subset of emoji characters as used by GitHub (based on the list https://api.github.←-
com/emojis). An emoji is created using the \emoji command. For example \emoji smile or \emoji
:smile: both produce .
27.1 Representation
For the different doxygen output types there is an output defined:
• Unicode code sequence, the actual representation is depending on the possibilities of the fonts loaded:
– HTML
– DocBook
– RTF, converted to UTF-16 representation.
• Image
– LATEX, in case the image can be found (see Emoji image retrieval) otherwise the plain emoji text (i.e.
:<text>:) is displayed
• plain emoji text (i.e. :<text>:)
– man
– perl
• For XML there is a dedicated <emoji> tag with name and unicode attributes.
27.2 Emoji image retrieval

In the list of images can be downloaded via the following Python script:
# script to download the emoticons from GitHub and to produce a table for
# inclusion in doxygen. Works with python 2.7+ and python 3.x
import json
import os
import argparse
import re
try:
import urllib.request as urlrequest
except ImportError:
import urllib as urlrequest
unicode_re = re.compile(r’.*?/unicode/(.*?).png\?.*’)
def get_emojis():
response = urlrequest.urlopen(’https://api.github.com/emojis’)
raw_data = response.read()
return json.loads(raw_data)
def download_images(dir_name):
if not os.path.exists(dir_name):
os.makedirs(dir_name)

220 Emoji support
json_data = get_emojis()
num_items = len(json_data)
cur_item=0
for image,url in sorted(json_data.items()):
image_name = image+’.png’
cur_item=cur_item+1
if url.find(’/unicode/’)==-1 or not os.path.isfile(dir_name+’/’+image_name):
with open(dir_name+’/’+image_name,’wb’) as file:
print(’%s/%s: fetching %s’ % (cur_item,num_items,image_name))
file.write(urlrequest.urlopen(url).read())
else:
print(’%s/%s: skipping %s’ % (cur_item,num_items,image_name))
def produce_table():
json_data = get_emojis()
lines = []
for image,url in sorted(json_data.items()):
match = unicode_re.match(url)
if match:
unicodes = match.group(1).split(’-’)
unicodes_html = ”.join(["&#x"+x+";" for x in unicodes])
image_str = "\":"+image+":\","
unicode_str = "\""+unicodes_html+"\""
lines.append(’ { %-42s %-38s }’ % (image_str,unicode_str))
out_str = ’,\n’.join(lines)
print("{")
print(out_str)
print("};")
if __name__=="__main__":
parser = argparse.ArgumentParser()
group = parser.add_mutually_exclusive_group()
group.add_argument(’-d’,’--dir’,help=’directory to place images in’)
group.add_argument(’-t’,’--table’,help=’generate code fragment’,action=’store_true’)
args = parser.parse_args()
if args.table:
produce_table()
else:
download_images(args.dir)
When invoking it with the -d image_dir option the images will by downloaded in the image_dir directory.
By means of the doxygen configuration parameter LATEX_EMOJI_DIRECTORY the requested directory can be
selected.
For convenience a zip with the result of running the script can also be downloaded from https://www.←-
doxygen.nl/dl/github_emojis.zip
For an overview of the supported emoji one can issue the command:
doxygen -f emoji <outputFileName>

Part III
Developers Manual
Chapter 28
Internationalization
Support for multiple languages
Doxygen has built-in support for multiple languages. This means that the text fragments, generated by doxygen, can
be produced in languages other than English (the default). The output language is chosen through the configuration
option OUTPUT_LANGUAGE in the configuration file (with default name and known as Doxyfile). To switch between
languages inside a comment block the \∼ command can be used.
Currently (version 1.9.7), 42 languages are supported (sorted alphabetically): Afrikaans, Arabic, Armenian, Brazilian
Portuguese, Bulgarian, Catalan, Chinese, Chinese Traditional, Croatian, Czech, Danish, Dutch, English, Esperanto,
Finnish, French, German, Greek, Hindi, Hungarian, Indonesian, Italian, Japanese (+En), Korean (+En), Latvian,
Lithuanian, Macedonian, Norwegian, Persian, Polish, Portuguese, Romanian, Russian, Serbian, SerbianCyrillic,
Slovak, Slovene, Spanish, Swedish, Turkish, Ukrainian, and Vietnamese..
The table of information related to the supported languages follows. It is sorted by language alphabetically. The
Status column was generated from sources and shows approximately the last version when the translator was
updated.
Language Maintainer Contact address Status

Afrikaans Johan Prinsloo johan at zippysnoek dot com 1.6.0
Arabic Moaz Reyad [resigned] moazreyad at yahoo dot com 1.4.6
Muhammad Bashir Al-Noimi mbnoimi at gmail dot com
Armenian Armen Tangamyan armen dot tangamyan at anu dot edu dot au 1.8.0
Brazilian Portuguese Fabio "FJTC" Jun Takada Chino jun-chino at uol dot com dot br up-to-date
Bulgarian Kiril Kirilov kpkirilov at abv dot bg 1.9.4
Catalan Maximiliano Pin max dot pin at bitroit dot com 1.8.0
Albert Mora [unreachable] amora at iua dot upf dot es
Chinese Lian Yang lian dot yang dot cn at gmail dot com 1.9.4
Li Daobing lidaobing at gmail dot com
Wei Liu liuwei at asiainfo dot com
Chinese Traditional Daniel YC Lin dlin dot tw at gmail dot com 1.8.15
Gary Lee garywlee at gmail dot com
Croatian Boris Bralo boris dot bralo at gmail dot com 1.8.2
Czech Petr Přikryl prikryl at atlas dot cz 1.9.6
Danish Poul-Erik Hansen pouhan at gnotometrics dot dk 1.8.0
Erik Søe Sørensen eriksoe+doxygen at daimi dot au dot dk
Dutch Dimitri van Heesch doxygen at gmail dot com up-to-date
English Dimitri van Heesch doxygen at gmail dot com up-to-date
Esperanto Ander Martínez ander dot basaundi at gmail dot com 1.8.4
Finnish Antti Laine antti dot a dot laine at tut dot fi 1.6.0
French David Martinet contact at e-concept-applications dot fr 1.9.5
Xavier Outhier xouthier at yahoo dot fr
Benoît BROSSE Benoit dot BROSSE at ingenico dot com
German Peter Grotrian Peter dot Grotrian at pdv-FS dot de 1.8.15
Jens Seidel jensseidel at users dot sf dot net
Greek Paul Gessos gessos dot paul at yahoo dot gr 1.9.6
Hindi Harsh Rathod hrathore50 at ymail dot com 1.9.4
Hungarian Ákos Kiss akiss at users dot sourceforge dot net 1.8.15
Földvári György [unreachable] foldvari lost at cyberspace
Indonesian Hendy Irawan ceefour at gauldong dot net 1.8.0
Italian Alessandro Falappa alex dot falappa at gmail dot com 1.8.15
Ahmed Aldo Faisal aaf23 at cam dot ac dot uk
Japanese Suzumizaki-Kimikata szmml at h12u.com 1.8.15
Hiroki Iseri goyoki at gmail dot com

224 Internationalization
Ryunosuke Satoh sun594 at hotmail dot com

Kenji Nagamatsu [unreachable] naga at joyful dot club dot ne dot jp
Iwasa Kazmi [unreachable] iwasa at cosmo-system dot jp
JapaneseEn see the Japanese language English based
Korean Kim Taedong fly1004 at gmail dot com 1.8.15
SooYoung Jung jung5000 at gmail dot com
Richard Kim [unreachable] ryk at dspwiz dot com
KoreanEn see the Korean language English based
Latvian Lauris lauris at nix.lv 1.8.4
Lithuanian Tomas Simonaitis [unreachable] haden at homelan dot lt 1.4.6
Mindaugas Radzius [unreachable] mindaugasradzius at takas dot lt
Aidas Berukstis [unreachable] aidasber at takas dot lt
– searching for the maintainer – [Please, try to help to find someone.]
Macedonian Slave Jovanovski slavejovanovski at yahoo dot com 1.6.0
Norwegian Lars Erik Jordet lejordet at gmail dot com 1.4.6
Persian Ali Nadalizadeh nadalizadeh at gmail dot com 1.7.5
Polish Piotr Kaminski [unreachable] Piotr dot Kaminski at ctm dot gdynia dot pl 1.8.2
Grzegorz Kowal [unreachable] g_kowal at poczta dot onet dot pl
Krzysztof Kral krzysztof dot kral at gmail dot com
Portuguese Rui Godinho Lopes [resigned] rgl at ruilopes dot com up-to-date
Fabio "FJTC" Jun Takada Chino jun-chino at uol dot com dot br
Romanian Ionut Dumitrascu reddumy at yahoo dot com 1.8.15
Alexandru Iosup aiosup at yahoo dot com
Russian Brilliantov Kirill Vladimirovich brilliantov at byterg dot ru 1.8.15
Alexandr Chelpanov cav at cryptopro dot ru
Serbian Dejan Milosavljevic [unreachable] dmilos at email dot com 1.6.0
SerbianCyrillic Nedeljko Stefanovic stenedjo at yahoo dot com 1.6.0
Slovak Kali+Laco Švec [the Slovak language advisors] 1.8.15
Petr Přikryl prikryl at atlas dot cz
Slovene Matjaž Ostroveršnik matjaz dot ostroversnik at ostri dot org 1.4.6
Spanish Bartomeu bartomeu at loteria3cornella dot com 1.9.6
Francisco Oltra Thennet [unreachable] foltra at puc dot cl
David Vaquero david at grupoikusnet dot com
Swedish Björn Palmqvist bjorn.palmqvist at aidium.se 1.9.6
Turkish Emin Ilker Cetinbas niw3 at yahoo dot com 1.7.5
Ukrainian Olexij Tkatchenko [resigned] olexij at tkatchenko dot com 1.8.4
Petro Yermolenko python at i dot ua
Vietnamese Dang Minh Tuan tuanvietkey at gmail dot com 1.6.0
Most people on the list have indicated that they were also busy doing other things, so if you want to help to speed
things up please let them (or me) know.
If you want to add support for a language that is not yet listed please read the next section.
Adding a new language to doxygen
This short HOWTO explains how to add support for the new language to doxygen:
Just follow the following steps:
1. Tell me for which language (say YourLanguage) you want to add support. If no one else is already working
on support for that language, you will be assigned as the maintainer for the language.
2. Add to the file doxygen/src/config.xml, at the appropriate place in the OUTPUT_LANGUAGE part,
the line:
<value name=’YourLanguage’/>
3. Create a copy of doxygen/src/translator_en.h and name it doxygen/src/translator_←-

<your_2_letter_country_code>.h I'll use xx in the rest of this document (and XX for the upper-
case version).
4. Edit doxygen/src/language.cpp: Add the following code:
#include<translator_xx.h>
Now, in setTranslator() add
case OUTPUT_LANGUAGE_t::YourLanguage: theTranslator = new TranslatorYourLanguage; break;
5. Edit doxygen/src/translator_xx.h:

225
• Use the UTF-8 capable editor and open the file using the UTF-8 mode (non BOM mode).
• Rename TRANSLATOR_EN_H to TRANSLATOR_XX_H twice (i.e. in the #ifndef and #define
preprocessor commands at the beginning of the file).
• Rename TranslatorEnglish to TranslatorYourLanguage
• In the member idLanguage() change ënglish¨ into the name of your language (use lower case char-
acters only). Depending on the language you may also wish to change the member functions latex←-
LanguageSupportCommand() and other (you will recognize them when you start the work).
• Edit all the strings that are returned by the member functions that start with tr. Try to match punctuation
and capitals! To enter special characters (with accents) you can:
– Enter them directly if your keyboard supports that. Recall that the text is expected to be saved using
the UTF-8 encoding. Doxygen will translate the characters to proper LATEX and leaves the HTML
and man output in UTF-8.
– Use HTML codes like ä for an a with an umlaut (i.e. ä). See the HTML specification for
the codes.
6. Edit doxygen/doc/maintainers.txt and add yourself to the list of maintainers like:

TranslatorYourLanguage
<your name>: <your dot email at your dot domain>
7. Build the documentation by giving the appropriate build command (like: make docs).
8. Now you can use OUTPUT_LANGUAGE = your_language_name in the config file to generate output
in your language.
9. The preferred way is to clone the doxygen repository at GitHub and make a Pull Request. Alternatively send
translator_xx.h to me so I can add it to doxygen. Send also your name and e-mail address to be
included in the maintainers.txt list.
Maintaining a language
New versions of doxygen may use new translated sentences. In such situation, the Translator class requires
implementation of new methods – its interface changes. Of course, the English sentences need to be translated
to the other languages. At least, new methods have to be implemented by the language-related translator class;
otherwise, doxygen wouldn't even compile. Waiting until all language maintainers have translated the new sentences
and sent the results would not be very practical. The following text describes the usage of translator adapters to
solve the problem.
The role of Translator Adapters. Whenever the Translator class interface changes in the new release, the
new class TranslatorAdapter_x_y_z is added to the translator_adapter.h file (here x, y, and z are
numbers that correspond to the current official version of doxygen). All translators that previously derived from the
Translator class now derive from this adapter class.
The TranslatorAdapter_x_y_z class implements the new, required methods. If the new method replaces
some similar but obsolete method(s) (e.g. if the number of arguments changed and/or the functionality of the older
method was changed or enriched), the TranslatorAdapter_x_y_z class may use the obsolete method to
get the result which is as close as possible to the older result in the target language. If it is not possible, the result
(the default translation) is obtained using the English translator, which is (by definition) always up-to-date.
For example, when the new trFile() method with parameters (to determine the capitalization of the first letter
and the singular/plural form) was introduced to replace the older method trFiles() without arguments, the
following code appeared in one of the translator adapter classes:
/*! This is the default implementation of the obsolete method

* used in the documentation of a group before the list of
* links to documented files. This is possibly localized.
*/
virtual QCString trFiles()
{ return "Files"; }
/*! This is the localized implementation of newer equivalent

* using the obsolete method trFiles().
*/
virtual QCString trFile(bool first_capital, bool singular)
{
if (first_capital && !singular)

return trFiles(); // possibly localized, obsolete method

else
return english.trFile(first_capital, singular);
}
The trFiles() is not present in the TranslatorEnglish class, because it was removed as obsolete. How-
ever, it was used until now and its call was replaced by
trFile(true, false)
in the doxygen source files. Probably, many language translators implemented the obsolete method, so it perfectly
makes sense to use the same language dependent result in those cases. The TranslatorEnglish does not
implement the old method. It derives from the abstract Translator class. On the other hand, the old translator
for a different language does not implement the new trFile() method. Because of that it is derived from another
base class – TranslatorAdapter_x_y_z. The TranslatorAdapter_x_y_z class has to implement
the new, required trFile() method. However, the translator adapter would not be compiled if the trFiles()
method was not implemented. This is the reason for implementing the old method in the translator adapter class
(using the same code, that was removed from the TranslatorEnglish).
The simplest way would be to pass the arguments to the English translator and to return its result. Instead, the
adapter uses the old trFiles() in one special case – when the new trFile(true, false) is called. This
is the mostly used case at the time of introducing the new method – see above. While this may look too complicated,
the technique allows the developers of the core sources to change the Translator interface, while the users may not
even notice the change. Of course, when the new trFile() is used with different arguments, the English result
is returned and it will be noticed by non English users. Here the maintainer of the language translator should
implement at least that one particular method.
What says the base class of a language translator? If the language translator class inherits from any adapter
class then maintenance is needed. In such case, the language translator is considered not up-to-date. On the other
hand, if the language translator derives directly from the abstract class Translator, the language translator is
up-to-date.
The translator adapter classes are chained so that the older translator adapter class uses the one-step-newer
translator adapter as the base class. The newer adapter does less adapting work than the older one. The oldest
adapter class derives (indirectly) from all of the adapter classes. The name of the adapter class is chosen so that
its suffix is derived from the previous official version of doxygen that did not need the adapter. This way, one can
say approximately, when the language translator class was last updated – see details below.
The newest translator adapter derives from the abstract TranslatorAdapterBase class that derives directly
from the abstract Translator class. It adds only the private English-translator member for easy implementation
of the default translation inside the adapter classes, and it also enforces implementation of one method for notifying
the user that the language translation is not up-to-date (because of that some sentences in the generated files may
appear in English).
Once the oldest adapter class is not used by any of the language translators, it can be removed from the doxygen
project. The maintainers should try to reach the state with the minimal number of translator adapter classes.
To simplify the maintenance of the language translator classes for the supported languages, the
translator.py Python script was developed (located in doxygen/doc directory). It extracts the impor-
tant information about obsolete and new methods from the source files for each of the languages. The information
is stored in the translator report ASCII file (translator_report.txt).
Looking at the base class of the language translator, the script guesses also the status of the translator – see the
last column of the table with languages above. The translator.py is called automatically when the doxygen
documentation is generated. You can also run the script manually whenever you feel that it can help you. Of course,
you are not forced to use the results of the script. You can find the same information by looking at the adapter class
and its base classes.
How should I update my language translator? First, you should be the language maintainer, or you should
let him/her know about the changes. The following text was written for the language maintainers as the primary
audience.
There are several approaches to be taken when updating your language. If you are not extremely busy, you should
always chose the most radical one. When the update takes much more time than you expected, you can always
decide use some suitable translator adapter to finish the changes later and still make your translator working.
The most radical way of updating the language translator is to make your translator class derive directly from
the abstract class Translator and provide translations for the methods that are required to be implemented – the
compiler will tell you if you forgot to implement some of them. If you are in doubt, have a look at the Translator←-
English class to recognize the purpose of the implemented method. Looking at the previously used adapter class

227
may help you sometimes, but it can also be misleading because the adapter classes do implement also the obsolete
methods (see the previous trFiles() example).
In other words, the up-to-date language translators do not need the TranslatorAdapter_x_y_z classes at
all, and you do not need to implement anything else than the methods required by the Translator class (i.e. the pure
virtual methods of the Translator – they end with =0;).
If everything compiles fine, try to run translator.py, and have a look at the translator report (ASCII file) at
the doxygen/doc directory. Your translator is marked as up-to-date only if the script does not detect anything
special. If the translator uses the Translator base class, there still may be some remarks related to your source
code. In the case, the translator is marked as almost up-to-date. Namely, the obsolete methods–that are not used
at all–may be listed in the section for your language. Simply, remove their code (and run the translator.py
again). Also, you will be informed when you forgot to change the base class of your translator class to some newer
adapter class or directly to the Translator class.
If you do not have time to finish all the updates you should still start with the most radical approach as described
above. You can always change the base class to the translator adapter class that implements all of the not-yet-
implemented methods.
If you prefer to update your translator gradually, have a look at TranslatorEnglish (the translator←-
_en.h file). Inside, you will find the comments like new since 1.2.4 that separate always a number of
methods that were implemented in the stated version. Do implement the group of methods that are placed below
the comment that uses the same version numbers as your translator adapter class. (For example, your translator
class have to use the TranslatorAdapter_1_2_4, if it does not implement the methods below the comment
new since 1.2.4. When you implement them, your class should use a newer translator adapter.
Run the translator.py script occasionally and give it your xx identification (from translator_xx.h) to
create the translator report shorter (also produced faster) – it will contain only the information related to your trans-
lator. Once you reach the state when the base class should be changed to some newer adapter, you will see the
note in the translator report.
Warning: Don't forget to compile doxygen to discover, whether it is compilable. The translator.py does not
check if everything is correct with respect to the compiler. Because of that, it may lie sometimes about the necessary
base class.
The most obsolete language translators would lead to implementation of too complicated adapters. Because of
that, doxygen developers may decide to derive such translators from the TranslatorEnglish class, which is
by definition always up-to-date.
When doing so, all the missing methods will be replaced by the English translation. This means that not-
implemented methods will always return the English result. Such translators are marked using the word obsolete.
You should read it really obsolete. No guess about the last update can be done.
Often, it is possible to construct better result from the obsolete methods. Because of that, the translator adapter
classes should be used if possible. On the other hand, implementation of adapters for really obsolete translators
brings too much maintenance and run-time overhead.


Chapter 29
Perl Module Output
Since version 1.2.18, doxygen can generate a new output format we have called the "Perl Module output format".
It has been designed as an intermediate format that can be used to generate new and customized output without
having to modify the doxygen source. Therefore, its purpose is similar to the XML output format that can be also
generated by doxygen. The XML output format is more standard, but the Perl Module output format is possibly
simpler and easier to use.
The Perl Module output format is still experimental at the moment and could be changed in incompatible ways
in future versions, although this should not be very probable. It is also lacking some features of other doxygen
backends. However, it can be already used to generate useful output, as shown by the Perl Module-based LATEX
generator.
Please report any bugs or problems you find in the Perl Module backend or the Perl Module-based LATEX generator
to the doxygen issue tracker. Suggestions are welcome as well (see also: How to report a bug).
29.1 Usage
When the GENERATE_PERLMOD tag is enabled in the Doxyfile, running doxygen generates a number of files
in the perlmod/ subdirectory of your output directory. These files are the following:
• DoxyDocs.pm: This is the Perl module that actually contains the documentation, in the Perl Module format
described below.
• DoxyModel.pm: This Perl module describes the structure of DoxyDocs.pm, independently of the actual
documentation. See below for details.
• doxyrules.make: This file contains the make rules to build and clean the files that are generated from
the Doxyfile. Also contains the paths to those files and other relevant information. This file is intended to
be included by your own Makefile.
• Makefile: This is a simple Makefile including doxyrules.make.
To make use of the documentation stored in DoxyDocs.pm you can use one of the default Perl Module-based
generators provided by doxygen (at the moment this includes the Perl Module-based LATEX generator, see below) or
write your own customized generator. This should not be too hard if you have some knowledge of Perl and it's the
main purpose of including the Perl Module backend in doxygen. See below for details on how to do this.
29.2 Using the LaTeX generator.

The Perl Module-based LATEX generator is pretty experimental and incomplete at the moment, but you could find it
useful nevertheless. It can generate documentation for functions, typedefs and variables within files and classes
and can be customized quite a lot by redefining TEX macros. However, there is still no documentation on how to do
this.
Setting the PERLMOD_LATEX tag to YES in the Doxyfile enables the creation of some additional files in the
perlmod/ subdirectory of your output directory. These files contain the Perl scripts and LATEX code necessary to
generate PDF and DVI output from the Perl Module output, using pdflatex and latex respectively. Rules to
automate the use of these files are also added to doxyrules.make and the Makefile.

230 Perl Module Output
The additional generated files are the following:

• doxylatex.pl: This Perl script uses DoxyDocs.pm and DoxyModel.pm to generate doxydocs.←-
tex, a TEX file containing the documentation in a format that can be accessed by LATEX code. This file is not
directly LaTeXable.
• doxyformat.tex: This file contains the LATEX code that transforms the documentation from doxydocs.tex
into LATEX text suitable to be LATEX'ed and presented to the user.
• doxylatex-template.pl: This Perl script uses DoxyModel.pm to generate doxytemplate.←-

tex, a TEX file defining default values for some macros. doxytemplate.tex is included by doxyformat.←-
tex to avoid the need of explicitly defining some macros.
• doxylatex.tex: This is a very simple LATEX document that loads some packages and includes
doxyformat.tex and doxydocs.tex. This document is LATEX'ed to produce the PDF and DVI doc-
umentation by the rules added to doxyrules.make.
29.2.1 Creation of PDF and DVI output

To try this you need to have installed latex, pdflatex and the packages used by doxylatex.tex.
1. Update your Doxyfile to the latest version using:
doxygen -u Doxyfile
2. Set both GENERATE_PERLMOD and PERLMOD_LATEX tags to YES in your Doxyfile.
3. Run doxygen on your Doxyfile:

doxygen Doxyfile
4. A perlmod/ subdirectory should have appeared in your output directory. Enter the perlmod/ subdirectory
and run:
make pdf
This should generate a doxylatex.pdf with the documentation in PDF format.
5. Run:
make dvi
This should generate a doxylatex.dvi with the documentation in DVI format.
29.3 Documentation format.

The Perl Module documentation generated by doxygen is stored in DoxyDocs.pm. This is a very simple Perl
module that contains only two statements: an assignment to the variable $doxydocs and the customary 1;
statement which usually ends Perl modules.
The documentation is stored in the variable $doxydocs, which can then be accessed by a Perl script using
DoxyDocs.pm.
$doxydocs contains a tree-like structure composed of three types of nodes: strings, hashes and lists.
• Strings: These are normal Perl strings. They can be of any length can contain any character. Their
semantics depends on their location within the tree. This type of node has no children.
• Hashes: These are references to anonymous Perl hashes. A hash can have multiple fields, each with a
different key. The value of a hash field can be a string, a hash or a list, and its semantics depends on the key
of the hash field and the location of the hash within the tree. The values of the hash fields are the children of
the node.
• Lists: These are references to anonymous Perl lists. A list has an undefined number of elements, which
are the children of the node. Each element has the same type (string, hash or list) and the same semantics,
depending on the location of the list within the tree.
As you can see, the documentation contained in $doxydocs does not present any special impediment to be
processed by a simple Perl script.

29.4 Data structure 231
29.4 Data structure

You might be interested in processing the documentation contained in DoxyDocs.pm without needing to take into
account the semantics of each node of the documentation tree. For this purpose, doxygen generates a Doxy←-
Model.pm file which contains a data structure describing the type and children of each node in the documentation
tree.
The rest of this section is to be written yet, but in the meantime you can look at the Perl scripts generated by doxygen
(such as doxylatex.pl or doxytemplate-latex.pl) to get an idea on how to use DoxyModel.pm.
29.5 Perl Module Tree Nodes

Nodes in the documentation tree of the Perl Module output format.
This is a description of the structure of the documentation tree in DoxyDocs.pm. Each item in the list below
describes a node in the tree, and the format of the description is as follows:
• [ key => ] Name (type). Explanation of the content.
Where
• The ¨key =>¨ part only appears if the parent node is a hash. ¨key¨ is the key for this node.
• ¨Name¨ is a unique name for the node, defined in DoxyModel.pm.
• ¨(type)¨ is the type of the node: ¨string¨ for string nodes, ¨hash¨ for hash nodes, ¨list¨ for list nodes, and ¨doc¨
for documentation subtrees. The structure of documentation subtrees is not described anywhere yet, but you
can look for example at doxylatex.pl to see how to process it.
The meaning of each node in the documentation tree is as follows:
• Root (hash). Root node.
– classes => Classes (list). Documented classes.
* Class (hash). A documented class.

· protected_members => ClassProtectedMembers (hash). Information about the protected
members in the class.
· members => ClassProtectedMemberList (list). protected member list.
· ClassProtectedMember (hash). A protected member.
· protection => ClassProtectedMemberProtection (string). Protection of the protected
member.
· detailed => ClassProtectedMemberDetailed (hash). Detailed information about the
protected member.
· doc => ClassProtectedMemberDetailedDoc (doc). Detailed documentation for the
protected member.
· see => ClassProtectedMemberSee (doc). ¨See also¨ documentation for the pro-
tected member.
· kind => ClassProtectedMemberKind (string). Kind of protected member (usually
¨variable¨).
· name => ClassProtectedMemberName (string). Name of the protected member.
· type => ClassProtectedMemberType (string). Data type of the protected member.
· detailed => ClassDetailed (hash). Detailed information about the class.
· doc => ClassDetailedDoc (doc). Detailed documentation block for the class.
· protected_typedefs => ClassProtectedTypedefs (hash). Information about the protected
typedefs in the class.
· members => ClassProtectedTypedefList (list). protected typedef list.
· ClassProtectedTypedef (hash). A protected typedef.
· protection => ClassProtectedTypedefProtection (string). Protection of the protected
typedef.

· detailed => ClassProtectedTypedefDetailed (hash). Detailed information about the

protected typedef.
· doc => ClassProtectedTypedefDetailedDoc (doc). Detailed documentation for the
protected typedef.
· see => ClassProtectedTypedefSee (doc). ¨See also¨ documentation for the pro-
tected typedef.
· kind => ClassProtectedTypedefKind (string). Kind of protected typedef (usually
¨typedef¨).
· name => ClassProtectedTypedefName (string). Name of the protected typedef.
· type => ClassProtectedTypedefType (string). Data type of the protected typedef.
· name => ClassName (string). Name of the class.
· private_members => ClassPrivateMembers (hash). Information about the private members
in the class.
· members => ClassPrivateMemberList (list). private member list.
· ClassPrivateMember (hash). A private member.
· protection => ClassPrivateMemberProtection (string). Protection of the private
member.
· detailed => ClassPrivateMemberDetailed (hash). Detailed information about the pri-
vate member.
· doc => ClassPrivateMemberDetailedDoc (doc). Detailed documentation for the
private member.
· see => ClassPrivateMemberSee (doc). ¨See also¨ documentation for the private
member.
· kind => ClassPrivateMemberKind (string). Kind of private member (usually ¨vari-
able¨).
· name => ClassPrivateMemberName (string). Name of the private member.
· type => ClassPrivateMemberType (string). Data type of the private member.
· private_typedefs => ClassPrivateTypedefs (hash). Information about the private typedefs in
the class.
· members => ClassPrivateTypedefList (list). private typedef list.
· ClassPrivateTypedef (hash). A private typedef.
· protection => ClassPrivateTypedefProtection (string). Protection of the private type-
def.
· detailed => ClassPrivateTypedefDetailed (hash). Detailed information about the pri-
vate typedef.
· doc => ClassPrivateTypedefDetailedDoc (doc). Detailed documentation for the
private typedef.
· see => ClassPrivateTypedefSee (doc). ¨See also¨ documentation for the private
typedef.
· kind => ClassPrivateTypedefKind (string). Kind of private typedef (usually ¨typedef¨).
· name => ClassPrivateTypedefName (string). Name of the private typedef.
· type => ClassPrivateTypedefType (string). Data type of the private typedef.
· protected_methods => ClassProtectedMethods (hash). Information about the protected
methods in the class.
· members => ClassProtectedMethodList (list). protected method list.
· ClassProtectedMethod (hash). A protected method.
· parameters => ClassProtectedMethodParams (list). List of the parameters of the
protected method.
· ClassProtectedMethodParam (hash). A parameter of the protected method.
· declaration_name => ClassProtectedMethodParamName (string). The name
of the parameter.
· type => ClassProtectedMethodParamType (string). The data type of the pa-
rameter.

29.5 Perl Module Tree Nodes 233
· protection => ClassProtectedMethodProtection (string). Protection of the protected

method.
· virtualness => ClassProtectedMethodVirtualness (string). Virtualness of the pro-
tected method.
· detailed => ClassProtectedMethodDetailed (hash). Detailed information about the
protected method.
· params => ClassProtectedMethodPDBlocks (list). List of parameter documenta-
tion blocks for the protected method.
· ClassProtectedMethodPDBlock (hash). A parameter documentation block for
the protected method.
· parameters => ClassProtectedMethodPDParams (list). Parameter list for this
parameter documentation block.
· ClassProtectedMethodPDParam (hash). A parameter documented by this
· name => ClassProtectedMethodPDParamName (string). Name of the
parameter.
· doc => ClassProtectedMethodPDDoc (doc). Documentation for this param-
eter documentation block.
· doc => ClassProtectedMethodDetailedDoc (doc). Detailed documentation for the
protected method.
· see => ClassProtectedMethodSee (doc). ¨See also¨ documentation for the pro-
tected method.
· return => ClassProtectedMethodReturn (doc). Documentation about the return
value of the protected method.
· kind => ClassProtectedMethodKind (string). Kind of protected method (usually
¨function¨).
· name => ClassProtectedMethodName (string). Name of the protected method.
· type => ClassProtectedMethodType (string). Data type returned by the protected
method.
· static => ClassProtectedMethodStatic (string). Whether the protected method is
static.
· public_typedefs => ClassPublicTypedefs (hash). Information about the public typedefs in the
class.
· members => ClassPublicTypedefList (list). public typedef list.
· ClassPublicTypedef (hash). A public typedef.
· protection => ClassPublicTypedefProtection (string). Protection of the public type-
def.
· detailed => ClassPublicTypedefDetailed (hash). Detailed information about the pub-
lic typedef.
· doc => ClassPublicTypedefDetailedDoc (doc). Detailed documentation for the
public typedef.
· see => ClassPublicTypedefSee (doc). ¨See also¨ documentation for the public
typedef.
· kind => ClassPublicTypedefKind (string). Kind of public typedef (usually ¨typedef¨).
· name => ClassPublicTypedefName (string). Name of the public typedef.
· type => ClassPublicTypedefType (string). Data type of the public typedef.
· public_members => ClassPublicMembers (hash). Information about the public members in
the class.
· members => ClassPublicMemberList (list). public member list.
· ClassPublicMember (hash). A public member.
· protection => ClassPublicMemberProtection (string). Protection of the public mem-
ber.
· detailed => ClassPublicMemberDetailed (hash). Detailed information about the pub-
lic member.

· doc => ClassPublicMemberDetailedDoc (doc). Detailed documentation for the

public member.
· see => ClassPublicMemberSee (doc). ¨See also¨ documentation for the public
member.
· kind => ClassPublicMemberKind (string). Kind of public member (usually ¨variable¨).
· name => ClassPublicMemberName (string). Name of the public member.
· type => ClassPublicMemberType (string). Data type of the public member.
· private_methods => ClassPrivateMethods (hash). Information about the private methods in
the class.
· members => ClassPrivateMethodList (list). private method list.
· ClassPrivateMethod (hash). A private method.
· parameters => ClassPrivateMethodParams (list). List of the parameters of the private
method.
· ClassPrivateMethodParam (hash). A parameter of the private method.
· declaration_name => ClassPrivateMethodParamName (string). The name of
the parameter.
· type => ClassPrivateMethodParamType (string). The data type of the parame-
ter.
· protection => ClassPrivateMethodProtection (string). Protection of the private
method.
· virtualness => ClassPrivateMethodVirtualness (string). Virtualness of the private
method.
· detailed => ClassPrivateMethodDetailed (hash). Detailed information about the pri-
vate method.
· params => ClassPrivateMethodPDBlocks (list). List of parameter documentation
blocks for the private method.
· ClassPrivateMethodPDBlock (hash). A parameter documentation block for the
private method.
· parameters => ClassPrivateMethodPDParams (list). Parameter list for this
· ClassPrivateMethodPDParam (hash). A parameter documented by this
· name => ClassPrivateMethodPDParamName (string). Name of the pa-
rameter.
· doc => ClassPrivateMethodPDDoc (doc). Documentation for this parameter
· doc => ClassPrivateMethodDetailedDoc (doc). Detailed documentation for the
private method.
· see => ClassPrivateMethodSee (doc). ¨See also¨ documentation for the private
method.
· return => ClassPrivateMethodReturn (doc). Documentation about the return value
of the private method.
· kind => ClassPrivateMethodKind (string). Kind of private method (usually ¨function¨).
· name => ClassPrivateMethodName (string). Name of the private method.
· type => ClassPrivateMethodType (string). Data type returned by the private method.
· static => ClassPrivateMethodStatic (string). Whether the private method is static.
· public_methods => ClassPublicMethods (hash). Information about the public methods in the
class.
· members => ClassPublicMethodList (list). public method list.
· ClassPublicMethod (hash). A public method.
· parameters => ClassPublicMethodParams (list). List of the parameters of the public
method.
· ClassPublicMethodParam (hash). A parameter of the public method.

29.5 Perl Module Tree Nodes 235
· declaration_name => ClassPublicMethodParamName (string). The name of the

parameter.
· type => ClassPublicMethodParamType (string). The data type of the parameter.
· protection => ClassPublicMethodProtection (string). Protection of the public
method.
· virtualness => ClassPublicMethodVirtualness (string). Virtualness of the public
method.
· detailed => ClassPublicMethodDetailed (hash). Detailed information about the pub-
lic method.
· params => ClassPublicMethodPDBlocks (list). List of parameter documentation
blocks for the public method.
· ClassPublicMethodPDBlock (hash). A parameter documentation block for the
public method.
· parameters => ClassPublicMethodPDParams (list). Parameter list for this
· ClassPublicMethodPDParam (hash). A parameter documented by this doc-
umentation block.
· name => ClassPublicMethodPDParamName (string). Name of the pa-
rameter.
· doc => ClassPublicMethodPDDoc (doc). Documentation for this parameter
· doc => ClassPublicMethodDetailedDoc (doc). Detailed documentation for the
public method.
· see => ClassPublicMethodSee (doc). ¨See also¨ documentation for the public
method.
· return => ClassPublicMethodReturn (doc). Documentation about the return value
of the public method.
· kind => ClassPublicMethodKind (string). Kind of public method (usually ¨function¨).
· name => ClassPublicMethodName (string). Name of the public method.
· type => ClassPublicMethodType (string). Data type returned by the public method.
· static => ClassPublicMethodStatic (string). Whether the public method is static.
– files => Files (list). Documented files.
* File (hash). A documented file.

· detailed => FileDetailed (hash). Detailed information about the file.
· doc => FileDetailedDoc (doc). Detailed documentation block for the file.
· functions => FileFunctions (hash). Information about the functions in the file.
· members => FileFunctionList (list). function list.
· FileFunction (hash). A function.
· parameters => FileFunctionParams (list). List of the parameters of the function.
· FileFunctionParam (hash). A parameter of the function.
· declaration_name => FileFunctionParamName (string). The name of the pa-
rameter.
· type => FileFunctionParamType (string). The data type of the parameter.
· protection => FileFunctionProtection (string). Protection of the function.
· virtualness => FileFunctionVirtualness (string). Virtualness of the function.
· detailed => FileFunctionDetailed (hash). Detailed information about the function.
· params => FileFunctionPDBlocks (list). List of parameter documentation blocks
for the function.
· FileFunctionPDBlock (hash). A parameter documentation block for the function.
· parameters => FileFunctionPDParams (list). Parameter list for this parameter
· FileFunctionPDParam (hash). A parameter documented by this documen-
tation block.

· name => FileFunctionPDParamName (string). Name of the parameter.

· doc => FileFunctionPDDoc (doc). Documentation for this parameter docu-
mentation block.
· doc => FileFunctionDetailedDoc (doc). Detailed documentation for the function.
· see => FileFunctionSee (doc). ¨See also¨ documentation for the function.
· return => FileFunctionReturn (doc). Documentation about the return value of the
function.
· kind => FileFunctionKind (string). Kind of function (usually ¨function¨).
· name => FileFunctionName (string). Name of the function.
· type => FileFunctionType (string). Data type returned by the function.
· static => FileFunctionStatic (string). Whether the function is static.
· name => FileName (string). Name of the file.
· variables => FileVariables (hash). Information about the variables in the file.
· members => FileVariableList (list). variable list.
· FileVariable (hash). A variable.
· protection => FileVariableProtection (string). Protection of the variable.
· detailed => FileVariableDetailed (hash). Detailed information about the variable.
· doc => FileVariableDetailedDoc (doc). Detailed documentation for the variable.
· see => FileVariableSee (doc). ¨See also¨ documentation for the variable.
· kind => FileVariableKind (string). Kind of variable (usually ¨variable¨).
· name => FileVariableName (string). Name of the variable.
· type => FileVariableType (string). Data type of the variable.
· typedefs => FileTypedefs (hash). Information about the typedefs in the file.
· members => FileTypedefList (list). typedef list.
· FileTypedef (hash). A typedef.
· protection => FileTypedefProtection (string). Protection of the typedef.
· detailed => FileTypedefDetailed (hash). Detailed information about the typedef.
· doc => FileTypedefDetailedDoc (doc). Detailed documentation for the typedef.
· see => FileTypedefSee (doc). ¨See also¨ documentation for the typedef.
· kind => FileTypedefKind (string). Kind of typedef (usually ¨typedef¨).
· name => FileTypedefName (string). Name of the typedef.
· type => FileTypedefType (string). Data type of the typedef.

Chapter 30
Doxygen's Internals
Doxygen's internals
Note that this section is still under construction!

The following picture shows how source files are processed by doxygen.
config file
Config parser
XML
get settings
HTML
input files drives LaTeX

C Preprocessor Language parser Data organiser Output generators
input entry
string tree RTF
Man
drives
entry drives
tree
Doc Parser
tag file parser
drives
Source Parser
drives
Figure 30.1: Data flow overview
The following sections explain the steps above in more detail.
Config parser
The configuration file that controls the settings of a project is parsed and the settings are stored in the singleton
class Config in src/config.h. The parser itself is written using flex and can be found in src/config.l.
This parser is also used directly by doxywizard, so it is put in a separate library.
Each configuration option has one of 5 possible types: String, List, Enum, Int, or Bool. The values of these
options are available through the global functions Config_getXXX(), where XXX is the type of the option.
The argument of these function is a string naming the option as it appears in the configuration file. For instance:
Config_getBool(¨GENERATE_TESTLIST¨) returns a reference to a boolean value that is TRUE if the test list
was enabled in the configuration file.

238 Doxygen's Internals
The function readConfiguration() in src/doxygen.cpp reads the command line options and then calls
the configuration parser.
C Preprocessor
The input files mentioned in the configuration file are (by default) fed to the C Preprocessor (after being piped
through a user defined filter if available).
The way the preprocessor works differs somewhat from a standard C Preprocessor. By default it does not do macro
expansion, although it can be configured to expand all macros. Typical usage is to only expand a user specified set
of macros. This is to allow macro names to appear in the type of function parameters for instance.
Another difference is that the preprocessor parses, but not actually includes code when it encounters a #include
(with the exception of #include found inside { ... } blocks). The reasons behind this deviation from the standard
is to prevent feeding multiple definitions of the same functions/classes to doxygen's parser. If all source files would
include a common header file for instance, the class and type definitions (and their documentation) would be present
in each translation unit.
The preprocessor is written using flex and can be found in src/pre.l. For condition blocks (#if) evaluation of
constant expressions is needed. For this a yacc based parser is used, which can be found in src/constexp.y
and src/constexp.l.
The preprocessor is invoked for each file using the preprocessFile() function declared in src/pre.h, and
will append the preprocessed result to a character buffer. The format of the character buffer is
0x06 file name 1

0x06 preprocessed contents of file 1
...
0x06 file name n
0x06 preprocessed contents of file n
Language parser
The preprocessed input buffer is fed to the language parser, which is implemented as a big state machine using
flex. It can be found in the file src/scanner.l. There is one parser for all languages (C/C++/Java/IDL). The
state variables insideIDL and insideJava are uses at some places for language specific choices.
The task of the parser is to convert the input buffer into a tree of entries (basically an abstract syntax tree). An entry
is defined in src/entry.h and is a blob of loosely structured information. The most important field is section
which specifies the kind of information contained in the entry.
Possible improvements for future versions:
• Use one scanner/parser per language instead of one big scanner.
• Move the first pass parsing of documentation blocks to a separate module.
• Parse defines (these are currently gathered by the preprocessor, and ignored by the language parser).
Data organizer
This step consists of many smaller steps, that build dictionaries of the extracted classes, files, namespaces, vari-
ables, functions, packages, pages, and groups. Besides building dictionaries, during this step relations (such as
inheritance relations), between the extracted entities are computed.
Each step has a function defined in src/doxygen.cpp, which operates on the tree of entries, built during
language parsing. Look at the ¨Gathering information¨ part of parseInput() for details.
The result of this step is a number of dictionaries, which can be found in the doxygen ¨namespace¨ defined in
src/doxygen.h. Most elements of these dictionaries are derived from the class Definition; The class
MemberDef, for instance, holds all information for a member. An instance of such a class can be part of a file (
class FileDef ), a class ( class ClassDef ), a namespace ( class NamespaceDef ), a group ( class Group←-
Def ), or a Java package ( class PackageDef ).
Tag file parser
If tag files are specified in the configuration file, these are parsed by a SAX based XML parser, which can be found
in src/tagreader.cpp. The result of parsing a tag file is the insertion of Entry objects in the entry tree. The
field Entry::tagInfo is used to mark the entry as external, and holds information about the tag file.

239
Documentation parser
Special comment blocks are stored as strings in the entities that they document. There is a string for the brief
description and a string for the detailed description. The documentation parser reads these strings and executes
the commands it finds in it (this is the second pass in parsing the documentation). It writes the result directly to the
output generators.
The parser is written in C++ and can be found in src/docparser.cpp. The tokens that are eaten by the parser
come from src/doctokenizer.l. Code fragments found in the comment blocks are passed on to the source
parser.
The main entry point for the documentation parser is validatingParseDoc() declared in src/docparser.←-
h. For simple texts with special commands validatingParseText() is used.
Source parser
If source browsing is enabled or if code fragments are encountered in the documentation, the source parser is
invoked.
The code parser tries to cross-reference to source code it parses with documented entities. It also does syntax
highlighting of the sources. The output is directly written to the output generators.
The main entry point for the code parser is parseCode() declared in src/code.h.
Output generators
After data is gathered and cross-referenced, doxygen generates output in various formats. For this it uses the
methods provided by the abstract class OutputGenerator. In order to generate output for multiple formats at
once, the methods of OutputList are called instead. This class maintains a list of concrete output generators,
where each method called is delegated to all generators in the list.
To allow small deviations in what is written to the output for each concrete output generator, it is possible to tem-
porarily disable certain generators. The OutputList class contains various disable() and enable() methods
for this. The methods OutputList::pushGeneratorState() and OutputList::popGenerator←-
State() are used to temporarily save the set of enabled/disabled output generators on a stack.
The XML is generated directly from the gathered data structures. In the future XML will be used as an intermediate
language (IL). The output generators will then use this IL as a starting point to generate the specific output formats.
The advantage of having an IL is that various independently developed tools written in various languages, could
extract information from the XML output. Possible tools could be:
• an interactive source browser
• a class diagram generator
• computing code metrics.
Debugging
Since doxygen uses a lot of flex code it is important to understand how flex works (for this one should read the
man page) and to understand what it is doing when flex is parsing some input. Fortunately, when flex is used
with the -d option it outputs what rules matched. This makes it quite easy to follow what is going on for a particular
input fragment.
To make it easier to toggle debug information for a given flex file I wrote the following perl script, which auto-
matically adds or removes -d from the correct line in the Makefile:
#!/usr/bin/perl
$file = shift @ARGV;

print "Toggle debugging mode for $file\n";
if (!-e "../src/${file}.l")
{
print STDERR "Error: file ../src/${file}.l does not exist!\n";
exit 1;
}
system("touch ../src/${file}.l");
unless (rename "src/CMakeFiles/doxymain.dir/build.make","src/CMakeFiles/doxymain.dir/build.make.old") {
print STDERR "Error: cannot rename src/CMakeFiles/doxymain.dir/build.make!\n";
exit 1;

240 Doxygen's Internals
}
if (open(F,"<src/CMakeFiles/doxymain.dir/build.make.old")) {
unless (open(G,">src/CMakeFiles/doxymain.dir/build.make")) {
print STDERR "Error: opening file build.make for writing\n";
exit 1;
}
print "Processing build.make...\n";
while (<F>) {
if ( s/flex \$$LEX_FLAGS$ -d(.*) ${file}.l/flex \$(LEX_FLAGS)$1 ${file}.l/ ) {
print "Disabling debug info for $file\n";
}
elsif ( s/flex \$$LEX_FLAGS$(.*) ${file}.l$/flex \$(LEX_FLAGS) -d$1 ${file}.l/ ) {
print "Enabling debug info for $file.l\n";
}
print G "$_";
}
close F;
unlink "src/CMakeFiles/doxymain.dir/build.make.old";
}
else {
print STDERR "Warning file src/CMakeFiles/doxymain.dir/build.make does not exist!\n";
}
# touch the file

$now = time;
utime $now, $now, $file;
Another way to get rules matching / debugging information from the flex code is setting LEX_FLAGS with make
(make LEX_FLAGS=-d).
By default a debug version of doxygen (i.e. an executable created with the CMake setting -DCMAKE_BUILD_←-
TYPE=Debug) will automatically have the flex debugging information for all flex codefiles.
Note that by running doxygen with -d lex you get information about which flex codefile is used. To see the
information of the flex parser, which is compiled with the flex debug option, you have to specify -d lex:<flex
codefile> when running doxygen.
Testing
Doxygen has a small set of tests available to test, some, code integrity. The tests can be run by means of
the command make tests. When only one or a few tests are required one can set the variable TEST←-
_FLAGS when running the test e.g. make TEST_FLAGS=¨--id 5¨ tests or for multiple tests make
TEST_FLAGS=¨--id 5 --id 7¨ tests. For a full set of possibilities give the command make TEST←-
_FLAGS=¨--help¨ tests. It is also possible to specify the TEST_FLAGS as an environment variable (works
also for testing through Visual Studio projects), e.g. setenv TEST_FLAGS ¨--id 5 --id 7¨ and make
tests.
Doxyfile differences
In case one has to communicate through e.g. a forum the configuration settings that are different from the standard
doxygen configuration file settings one can run the doxygen command: with the -x option and the name of the
configuration file (default is Doxyfile). The output will be a list of the not default settings (in Doxyfile format).
Alternatively also -x_noenv is possible which is identical to the -x option but without replacing the environment
variables and the CMake type replacement variables.

Appendices
Appendix A
Autolink Example
A.1 Class Documentation

A.1.1 Autolink_Test Class Reference
Public Types
• enum EType { Val1 , Val2 }

An enum type.
Public Member Functions
• Autolink_Test ()
constructor
• ∼Autolink_Test ()
destructor
• void member (int)
A member function.
• void member (int, int)
An overloaded member function.
Protected Attributes
• int var
A member variable.
Detailed Description
Since this documentation block belongs to the class Autolink_Test no link to Autolink_Test is generated.
Two ways to link to a constructor are: Autolink_Test and Autolink_Test().
Links to the destructor are: ∼Autolink_Test and ∼Autolink_Test().
A link to a member in this class: member().
More specific links to the each of the overloaded members: member(int) and member(int,int).
A link to the variable var.
A link to the global typedef B.
A link to the global enumeration type GlobEnum.
A link to a variable using another text as a link.
A link to the enumeration type EType.
A link to some enumeration values: Val1 and GVal1.
And last but not least a link to a file: autolink.cpp.

244 Autolink Example
See also
Inside a see also section any word is checked, so EType, Val1, GVal1, ∼Autolink_Test and member will be
replaced by links in HTML.
Member Enumeration Documentation
EType
enum Autolink_Test::EType
An enum type.
More details
Enumerator
Val1 enum value 1
Val2 enum value 2
Constructor & Destructor Documentation
Autolink_Test()
Autolink_Test::Autolink_Test ( )
constructor
details.
∼Autolink_Test()
Autolink_Test::∼Autolink_Test ( )
destructor
details.
Member Function Documentation
member() [1/2]
void Autolink_Test::member (
int )
A member function.
Details.
member() [2/2]
void Autolink_Test::member (
int ,
int )
An overloaded member function.
Details
The documentation for this class was generated from the following file:
• autolink.cpp
A.2 File Documentation

A.2.1 autolink.cpp File Reference
Classes
• class Autolink_Test

A.2 File Documentation 245
Macros
• #define ABS(x) (((x)>0)?(x):-(x))
Typedefs
• typedef Autolink_Test B
Enumerations
• enum GlobEnum { GVal1 , GVal2 }
Variables
• int globVar
Testing automatic link generation.

A link to a member of the Autolink_Test class: Autolink_Test::member,
More specific links to the each of the overloaded members: Autolink_Test::member(int) and Autolink_Test::member(int,int)
A link to a protected member variable of Autolink_Test: Autolink_Test::var,
A link to the global enumeration type GlobEnum.
A link to the destructor of the Autolink_Test class: Autolink_Test::∼Autolink_Test,
A link to the typedef B.
A link to the enumeration type Autolink_Test::EType
A link to some enumeration values Autolink_Test::Val1 and GVal2
Macro Definition Documentation
ABS
#define ABS(
x ) (((x)>0)?(x):-(x))
A macro definition.
Typedef Documentation
typedef Autolink_Test B
A type definition.
Enumeration Type Documentation
GlobEnum
enum GlobEnum
A global enum.
Enumerator
GVal1 global enum value 1

GVal2 global enum value 2

246 Autolink Example
Variable Documentation
globVar
int globVar
A global variable.

Appendix B
Resolving Typedef Example
B.1 Class Documentation

B.1.1 CoordStruct Struct Reference
Public Attributes
• float x
• float y
A coordinate pair.
Member Data Documentation
float CoordStruct::x
The x coordinate
float CoordStruct::y
The y coordinate
The documentation for this struct was generated from the following file:
• restypedef.cpp
B.2 File Documentation

B.2.1 restypedef.cpp File Reference
Classes
• struct CoordStruct
Typedefs
• typedef CoordStruct Coord
Functions
• Coord add (Coord c1, Coord c2)

248 Resolving Typedef Example
An example of resolving typedefs.
Coord
typedef CoordStruct Coord

Creates a type name for CoordStruct
Function Documentation
add()
Coord add (
Coord c1,
Coord c2 )
This function returns the addition of c1 and c2, i.e: (c1.x+c2.x,c1.y+c2.y)

Appendix C
Diagrams Example
C.1 Class Documentation

C.1.1 A Class Reference
#include <diagrams_a.h>
Inheritance diagram for A:
C D
Collaboration diagram for A:
A m_self
Public Attributes
• A ∗ m_self

250 Diagrams Example
m_self
A∗ A::m_self
• diagrams_a.h
C.1.2 B Class Reference

#include <diagrams_b.h>
Inheritance diagram for B:
Collaboration diagram for B:
A m_self
m_a
Public Attributes
• A ∗ m_a
m_a
A∗ B::m_a

C.1 Class Documentation 251
• diagrams_b.h
C.1.3 C Class Reference

#include <diagrams_c.h>
Inheritance diagram for C:
Collaboration diagram for C:
A m_self
m_a
C B
m_c m_d
Public Attributes
• D ∗ m_d
Public Attributes inherited from A
• A ∗ m_self
m_d
D∗ C::m_d

• diagrams_c.h
C.1.4 D Class Reference

#include <diagrams_d.h>
Inheritance diagram for D:
A B
Collaboration diagram for D:
A m_self
m_a
m_d m_c
Public Attributes
• C m_c

C.1 Class Documentation 253
Additional Inherited Members
Protected Attributes inherited from A
• A ∗ m_self
m_c
C D::m_c
• diagrams_d.h
C.1.5 E Class Reference

#include <diagrams_e.h>
Inheritance diagram for E:
A B

Collaboration diagram for E:
A m_self
m_a
m_d m_c
E C
Public Attributes inherited from D
• C m_c
Protected Attributes inherited from A
• A ∗ m_self
• diagrams_e.h

C.2 File Documentation 255
C.2 File Documentation

C.2.1 diagrams_a.h File Reference
This graph shows which files directly or indirectly include this file:
diagrams_a.h
diagrams_d.h
diagrams_e.h
Classes
• class A
C.2.2 diagrams_a.h
Go to the documentation of this file.
00001 #ifndef DIAGRAMS_A_H
00002 #define DIAGRAMS_A_H
00003 class A { public: A *m_self; };
00004 #endif
C.2.3 diagrams_b.h File Reference

diagrams_b.h
diagrams_d.h
diagrams_e.h

Classes
• class B
C.2.4 diagrams_b.h
00001 #ifndef DIAGRAMS_B_H
00002 #define DIAGRAMS_B_H
00003 class A;
00004 class B { public: A *m_a; };
00005 #endif
C.2.5 diagrams_c.h File Reference

#include ¨diagrams_c.h¨
Include dependency graph for diagrams_c.h:
diagrams_c.h
diagrams_c.h
Classes
• class C
C.2.6 diagrams_c.h
00001 #ifndef DIAGRAMS_C_H
00002 #define DIAGRAMS_C_H
00003 #include "diagrams_c.h"
00004 class D;
00005 class C : public A { public: D *m_d; };
00006 #endif
C.2.7 diagrams_d.h File Reference

#include ¨diagrams_a.h¨
#include ¨diagrams_b.h¨

C.2 File Documentation 257
Include dependency graph for diagrams_d.h:
diagrams_d.h
diagrams_a.h diagrams_b.h
diagrams_d.h
diagrams_e.h
Classes
• class D
C.2.8 diagrams_d.h
00001 #ifndef DIAGRAM_D_H
00002 #define DIAGRAM_D_H
00003 #include "diagrams_a.h"
00004 #include "diagrams_b.h"
00005 class C;
00006 class D : virtual protected A, private B { public: C m_c; };
00007 #endif

C.2.9 diagrams_e.h File Reference

#include ¨diagrams_d.h¨
Include dependency graph for diagrams_e.h:
diagrams_e.h
diagrams_d.h
diagrams_a.h diagrams_b.h
Classes
• class E
C.2.10 diagrams_e.h
00001 #ifndef DIAGRAM_E_H
00002 #define DIAGRAM_E_H
00003 #include "diagrams_d.h"
00004 class E : public D {};
00005 #endif

Appendix D
Modules Example
D.1 Module Documentation

D.1.1 The First Group
This is the first group.
Namespaces
• namespace N1
namespace N1 is in four groups
Classes
• class C1
class C1 in group 1
• class C2
class C2 in group 1
Functions
• void func ()
function in group 1
• void func2 ()
another function in group 1
• void func3 ()
yet another function in group 1
This is the first group.

More documentation for the first group.
D.1.2 The Second Group

This is the second group.
Namespaces
• namespace N1

260 Modules Example
Classes
• class C3
class C3 in group 2
• class C4
class C4 in group 2
This is the second group.
D.1.3 The Third Group

This is the third group.
Modules
• The Fourth Group

Group 4 is a subgroup of group 3.
Files
• file group.cpp
this file in group 3
Namespaces
• namespace N1
Classes
• class C5
class C5 in the third group.
This is the third group.
The Fourth Group
Namespaces
• namespace N1
D.1.4 The Fifth Group

This is the fifth group.
This is the fifth group.

D.2 Namespace Documentation 261
This is a section in group 5
This is another section in group 5
D.2 Namespace Documentation

D.2.1 N1 Namespace Reference
See also
The first group, The Second Group, The Third Group, The Fourth Group
Also see This is another section in group 5
D.3 Class Documentation

D.3.1 C1 Class Reference
class C1 in group 1
class C1 in group 1
• group.cpp

class C2 in group 1
class C2 in group 1
• group.cpp

class C3 in group 2
class C3 in group 2
• group.cpp

class C4 in group 2

262 Modules Example
class C4 in group 2
• group.cpp


• group.cpp
D.4 File Documentation

D.4.1 group.cpp File Reference
Classes
• class C1
class C1 in group 1
• class C2
class C2 in group 1
• class C3
class C3 in group 2
• class C4
class C4 in group 2
• class C5
Namespaces
• namespace N1
Functions
• void func ()
function in group 1
• void func2 ()
another function in group 1
• void func3 ()
yet another function in group 1

Appendix E
Member Groups Example
E.1 Class Documentation

E.1.1 Memgrp_Test Class Reference
A class.
• void ungroupedFunction ()
Function without group.
• void func1InGroup1 ()
Same documentation for both members.
Group2
Description of group 2.
Function 1 in group 2.
A class.
Details
func1InGroup1()
void Memgrp_Test::func1InGroup1 ( )
Details
func1InGroup2()
Details.

264 Member Groups Example
func2InGroup1()
Details
func2InGroup2()
void Memgrp_Test::func2InGroup2 ( ) [protected]

Details.
ungroupedFunction()
void Memgrp_Test::ungroupedFunction ( )
Function without group.
Details.
• memgrp.cpp
E.2 File Documentation

E.2.1 memgrp.cpp File Reference
Classes
• class Memgrp_Test
A class.
• #define A 1
• #define B 2
• void glob_func ()
docs for this file
#define A 1
one description for all members of this group (because DISTRIBUTE_GROUP_DOC is YES in the config file)
#define B 2
glob_func()
void glob_func ( )

Appendix F
Style Examples
F.1 After Block Example

F.1.1 Class Documentation
Afterdoc_Test Class Reference
#include <afterdoc.h>
Public Types
• enum EnumType { EVal1 , EVal2 }

An enum type.
• void member ()
a member function.
• int value
Detailed Description A test class
EnumType enum Afterdoc_Test::EnumType

An enum type.
The documentation block cannot be put after the enum!
Enumerator
EVal1 enum value 1
EVal2 enum value 2
value int Afterdoc_Test::value [protected]

an integer value
• afterdoc.h

266 Style Examples
F.1.2 File Documentation

afterdoc.h
00001 /*! A test class */
00002
00003 class Afterdoc_Test
00004 {
00005 public:
00006 /** An enum type.
00007 * The documentation block cannot be put after the enum!
00008 */
00009 enum EnumType
00010 {
00011 int EVal1, /**< enum value 1 */
00012 int EVal2 /**< enum value 2 */
00013 };
00014 void member(); //!< a member function.
00015
00016 protected:
00017 int value; /*!< an integer value */
00018 };
F.2 QT Style Example

QTstyle_Test Class Reference
A test class.
Public Types
• enum TEnum { TVal1 , TVal2 , TVal3 }

An enum.
• QTstyle_Test ()
A constructor.
• ∼QTstyle_Test ()
A destructor.
• int testMe (int a, const char ∗s)
A normal member taking two arguments and returning an integer value.
• virtual void testMeToo (char c1, char c2)=0
A pure virtual member.
Public Attributes
• enum QTstyle_Test::TEnum ∗ enumPtr

Enum pointer.
• enum QTstyle_Test::TEnum enumVar
Enum variable.
• int publicVar
A public variable.
• int(∗ handler )(int a, int b)
A function variable.
Detailed Description A test class.


F.2 QT Style Example 267
TEnum enum QTstyle_Test::TEnum

An enum.
More detailed enum description.
Enumerator
TVal1 Enum value TVal1.
QTstyle_Test() QTstyle_Test::QTstyle_Test ( )
A constructor.
∼QTstyle_Test() QTstyle_Test::∼QTstyle_Test ( )
A destructor.
testMe() int QTstyle_Test::testMe (

int a,
const char ∗ s )
A normal member taking two arguments and returning an integer value.
Parameters
a an integer argument.
s a constant character pointer.
Returns
The test results
See also
QTstyle_Test(), ∼QTstyle_Test(), testMeToo() and publicVar()
testMeToo() virtual void QTstyle_Test::testMeToo (

char c1,
char c2 ) [pure virtual]
See also
testMe()
Parameters
c1 the first argument.

c2 the second argument.

268 Style Examples
enumPtr enum QTstyle_Test::TEnum ∗ QTstyle_Test::enumPtr

Enum pointer.
Details.
enumVar enum QTstyle_Test::TEnum QTstyle_Test::enumVar

Enum variable.
Details.
handler int(∗ QTstyle_Test::handler) (int a, int b)

A function variable.
Details.
publicVar int QTstyle_Test::publicVar

A public variable.
Details.
• qtstyle.cpp
F.3 Javadoc Style Example

Javadoc_Test Class Reference
A test class.
Public Types
• enum TEnum { TVal1 , TVal2 , TVal3 }

An enum.
• Javadoc_Test ()
A constructor.
• ∼Javadoc_Test ()
A destructor.
• int testMe (int a, const char ∗s)
a normal member taking two arguments and returning an integer value.
• virtual void testMeToo (char c1, char c2)=0
Public Attributes
• enum Javadoc_Test::TEnum ∗ enumPtr

enum pointer.
• enum Javadoc_Test::TEnum enumVar
enum variable.
• int publicVar
a public variable.
• int(∗ handler )(int a, int b)
a function variable.

F.3 Javadoc Style Example 269
Detailed Description A test class.

TEnum enum Javadoc_Test::TEnum

An enum.
More detailed enum description.
Enumerator
TVal1 enum value TVal1.
Javadoc_Test() Javadoc_Test::Javadoc_Test ( )
A constructor.
∼Javadoc_Test() Javadoc_Test::∼Javadoc_Test ( )
A destructor.
testMe() int Javadoc_Test::testMe (

int a,
const char ∗ s )
a normal member taking two arguments and returning an integer value.
Parameters
a an integer argument.
s a constant character pointer.
See also
Javadoc_Test()
∼Javadoc_Test()
testMeToo()
publicVar()
Returns
The test results
testMeToo() virtual void Javadoc_Test::testMeToo (

char c1,
char c2 ) [pure virtual]

270 Style Examples
See also
testMe()
Parameters
c1 the first argument.

c2 the second argument.
enumPtr enum Javadoc_Test::TEnum ∗ Javadoc_Test::enumPtr

enum pointer.
Details.
enumVar enum Javadoc_Test::TEnum Javadoc_Test::enumVar

enum variable.
Details.
handler int(∗ Javadoc_Test::handler) (int a, int b)

a function variable.
Details.
publicVar int Javadoc_Test::publicVar

a public variable.
Details.
• jdstyle.cpp
F.4 Javadoc Banner Example

F.4.1 File Documentation
javadoc-banner.h File Reference
Functions
• void cstyle (int theory)

A brief history of JavaDoc-style (C-style) comments.
• void javadocBanner (int theory)
A brief history of JavaDoc-style (C-style) banner comments.
• void doxygenBanner (int theory)
A brief history of Doxygen-style banner comments.
cstyle() void cstyle (

int theory )
A brief history of JavaDoc-style (C-style) comments.
This is the typical JavaDoc-style C-style comment. It starts with two asterisks.
Parameters
theory Even if there is only one possible unified theory. it is just a set of rules and equations.

F.4 Javadoc Banner Example 271
doxygenBanner() void doxygenBanner (

int theory )
A brief history of Doxygen-style banner comments.
This is a Doxygen-style C-style ¨banner¨ comment. It starts with a ¨normal¨ comment and is then converted to a
¨special¨ comment block near the end of the first line. It is written this way to be more ¨visible¨ to developers who
are reading the source code. This style of commenting behaves poorly with clang-format.
Parameters
javadocBanner() void javadocBanner (

int theory )
A brief history of JavaDoc-style (C-style) banner comments.
This is the typical JavaDoc-style C-style ¨banner¨ comment. It starts with a forward slash followed by some number,
n, of asterisks, where n > 2. It's written this way to be more ¨visible¨ to developers who are reading the source code.
Often, developers are unaware that this is not (by default) a valid Doxygen comment block!
However, as long as JAVADOC_BLOCK = YES is added to the Doxyfile, it will work as expected.
This style of commenting behaves well with clang-format.
Parameters
javadoc-banner.h

00001 /**
00002 * A brief history of JavaDoc-style (C-style) comments.
00003 *
00004 * This is the typical JavaDoc-style C-style comment. It starts with two
00005 * asterisks.
00006 *
00007 * @param theory Even if there is only one possible unified theory. it is just a
00008 * set of rules and equations.
00009 */
00010 void cstyle( int theory );
00011
00012 /*******************************************************************************
00013 * A brief history of JavaDoc-style (C-style) banner comments.
00014 *
00015 * This is the typical JavaDoc-style C-style "banner" comment. It starts with
00016 * a forward slash followed by some number, n, of asterisks, where n > 2. It’s
00017 * written this way to be more "visible" to developers who are reading the
00018 * source code.
00019 *
00020 * Often, developers are unaware that this is not (by default) a valid Doxygen
00021 * comment block!
00022 *
00023 * However, as long as JAVADOC_BLOCK = YES is added to the Doxyfile, it will
00024 * work as expected.
00025 *
00026 * This style of commenting behaves well with clang-format.
00027 *
00030 ******************************************************************************/
00031 void javadocBanner( int theory );
00032
00033 /***************************************************************************//**
00034 * A brief history of Doxygen-style banner comments.
00035 *
00036 * This is a Doxygen-style C-style "banner" comment. It starts with a "normal"
00037 * comment and is then converted to a "special" comment block near the end of
00038 * the first line. It is written this way to be more "visible" to developers
00039 * who are reading the source code.
00040 * This style of commenting behaves poorly with clang-format.
00041 *

272 Style Examples
00044 ******************************************************************************/
00045 void doxygenBanner( int theory );

Appendix G
Structural Commands Example
G.1 File Documentation

G.1.1 structcmd.h File Reference
A Documented file.
Macros
• #define MAX(a, b) (((a)>(b))?(a):(b))

A macro that returns the maximum of a and b.
Typedefs
• typedef unsigned int UINT32

A type definition for a .
Functions
• int open (const char ∗, int)

Opens a file descriptor.
• int close (int)
Closes the file descriptor fd.
• size_t write (int, const char ∗, size_t)
Writes count bytes from buf to the filedescriptor fd.
• int read (int, char ∗, size_t)
Read bytes from a file descriptor.
Variables
• int errno
Contains the last error code.
A Documented file.
Details.
MAX
#define MAX(
a,
b ) (((a)>(b))?(a):(b))

274 Structural Commands Example
A macro that returns the maximum of a and b.

Details.
UINT32
typedef unsigned int UINT32

A type definition for a .
Details.
close()
int close (
int fd )
Closes the file descriptor fd.
Parameters
fd The descriptor to close.
open()
int open (
const char ∗ pathname,
int flags )
Opens a file descriptor.
Parameters
pathname The name of the descriptor.

flags Opening flags.
read()
int read (
int fd,
char ∗ buf,
size_t count )
Read bytes from a file descriptor.
Parameters
fd The descriptor to read from.

buf The buffer to read into.
count The number of bytes to read.
write()
size_t write (
int fd,
const char ∗ buf,
size_t count )

G.1 File Documentation 275
Writes count bytes from buf to the filedescriptor fd.
Parameters
fd The descriptor to write to.

buf The data buffer to write.
count The number of bytes to write.
errno
int errno
Contains the last error code.
Warning
Not thread safe!
G.1.2 structcmd.h
00001 /*! \file structcmd.h
00002 \brief A Documented file.
00003
00004 Details.
00005 */
00006
00007 /*! \def MAX(a,b)
00008 \brief A macro that returns the maximum of \a a and \a b.
00009
00010 Details.
00011 */
00012
00013 /*! \var typedef unsigned int UINT32
00014 \brief A type definition for a .
00015
00016 Details.
00017 */
00018
00019 /*! \var int errno
00020 \brief Contains the last error code.
00021
00022 \warning Not thread safe!
00023 */
00024
00025 /*! \fn int open(const char *pathname,int flags)
00026 \brief Opens a file descriptor.
00027
00028 \param pathname The name of the descriptor.
00029 \param flags Opening flags.
00030 */
00031
00032 /*! \fn int close(int fd)
00033 \brief Closes the file descriptor \a fd.
00034 \param fd The descriptor to close.
00035 */
00036
00037 /*! \fn size_t write(int fd,const char *buf, size_t count)
00038 \brief Writes \a count bytes from \a buf to the filedescriptor \a fd.
00039 \param fd The descriptor to write to.
00040 \param buf The data buffer to write.
00041 \param count The number of bytes to write.
00042 */
00043
00044 /*! \fn int read(int fd,char *buf,size_t count)
00045 \brief Read bytes from a file descriptor.
00046 \param fd The descriptor to read from.
00047 \param buf The buffer to read into.
00048 \param count The number of bytes to read.
00049 */
00050
00051 #define MAX(a,b) (((a)>(b))?(a):(b))
00052 typedef unsigned int UINT32;
00053 int errno;
00054 int open(const char *,int);
00055 int close(int);

276 Structural Commands Example
00056 size_t write(int,const char *, size_t);

00057 int read(int,char *,size_t);

Appendix H
Language Examples
H.1 Python Docstring Example

H.1.1 Namespace Documentation
docstring Namespace Reference
Classes
• class PyClass
Functions
• func ()
@package docstring
More details.
func() docstring.func ( )
Documentation for a function.
More details.
H.1.2 Class Documentation

docstring.PyClass Class Reference
• __init__ (self)
• PyMethod (self)
• _memVar
Documentation for a class.
More details.

278 Language Examples
__init__() docstring.PyClass.__init__ (
self )
The constructor.
PyMethod() docstring.PyClass.PyMethod (
self )
Documentation for a method.
_memVar docstring.PyClass._memVar [protected]

• docstring.py
H.1.3 File Documentation

docstring.py File Reference
Classes
• class docstring.PyClass
Namespaces
• namespace docstring
Functions
• docstring.func ()
H.2 Python Example

H.2.1 Namespace Documentation
pyexample Namespace Reference
Classes
• class PyClass
Functions
• func ()
Detailed Description Documentation for this module.

More details.

H.3 VHDL Example 279
func() pyexample.func ( )
More details.
H.2.2 Class Documentation

pyexample.PyClass Class Reference
• __init__ (self)
The constructor.
• PyMethod (self)
Static Public Attributes
• int classVar = 0;
A class variable.
• _memVar
a member variable
Detailed Description Documentation for a class.

More details.
PyMethod() pyexample.PyClass.PyMethod (
self )
Parameters
self The object pointer.
• pyexample.py
H.3 VHDL Example

H.3.1 Design Unit Documentation
mux_using_with Entity Reference
Mux entity brief description Detailed description of this mux design element.
Entities
• mux_using_with.behavior architecture
Architecture definition of the MUX.

280 Language Examples
Libraries
• ieee
Use standard library.
Use Clauses
• std_logic_1164
Use logic elements.
Ports
• din_0 in std_logic
Mux first input.
• din_1 in std_logic
Mux Second input.
• sel in std_logic
Select input.
• mux_out out std_logic
Mux output.
Detailed Description Mux entity brief description Detailed description of this mux design element.
The documentation for this design unit was generated from the following file:
• mux.vhdl
mux_using_with.behavior Architecture Reference

Architecture >> mux_using_with::behavior
Detailed Description Architecture definition of the MUX.

More details about this mux element.
The documentation for this design unit was generated from the following file:
• mux.vhdl
H.3.2 File Documentation

mux.vhdl File Reference
2:1 Mux using with-select
Entities
• mux_using_with entity
Mux entity brief description Detailed description of this mux design element.
• mux_using_with.behavior architecture
Detailed Description 2:1 Mux using with-select

Appendix I
Class Example
I.1 Class Documentation

I.1.1 Test Class Reference
This is a test class.
#include ïnc/class.h¨
This is a test class.

Some details about the Test class.
• class.h
I.2 File Documentation

I.2.1 class.h
00001 /* A dummy class */
00002
00003 class Test
00004 {
00005 };
00006
00007 /*! \class Test class.h "inc/class.h"
00008 * \brief This is a test class.
00009 *
00010 * Some details about the Test class.
00011 */

282 Class Example

Appendix J
Define Example
J.1 File Documentation

J.1.1 define.h File Reference
testing defines
Macros
• #define ABS(x) (((x)>0)?(x):-(x))

Computes the absolute value of its argument x.
• #define MAX(x, y) ((x)>(y)?(x):(y))
• #define MIN(x, y) ((x)>(y)?(y):(x))
testing defines
This is to test the documentation of defines.
ABS
#define ABS(
x ) (((x)>0)?(x):-(x))
Computes the absolute value of its argument x.
Parameters
x input value.
Returns
absolute value of x.
MAX
#define MAX(
x,
y ) ((x)>(y)?(x):(y))
Computes the maximum of x and y.
MIN
#define MIN(

284 Define Example
x,
y ) ((x)>(y)?(y):(x))
Computes the minimum of x and y.
J.1.2 define.h
00001 /*! \file define.h
00002 \brief testing defines
00003
00004 This is to test the documentation of defines.
00005 */
00006
00007 /* !
00008 \def MAX(x,y)
00009 Computes the maximum of \a x and \a y.
00010 */
00011
00012 /* !
00013 \brief Computes the absolute value of its argument \a x.
00014 \param x input value.
00015 \returns absolute value of \a x.
00016 */
00017 #define ABS(x) (((x)>0)?(x):-(x))
00018 #define MAX(x,y) ((x)>(y)?(x):(y))
00019 #define MIN(x,y) ((x)>(y)?(y):(x))
00020 /*!< Computes the minimum of \a x and \a y. */

Appendix K
Enum Example
K.1 Class Documentation

K.1.1 Enum_Test Class Reference
#include <enum.h>
Public Types
• enum TEnum { Val1 , Val2 }

• enum AnotherEnum { V1 , V2 }
The class description.
AnotherEnum
enum Enum_Test::AnotherEnum
Another enum, with inline docs
Enumerator
V1 value 1
V2 value 2
TEnum
enum Enum_Test::TEnum
A description of the enum type.
Enumerator
Val1 The description of the first enum value.
• enum.h

286 Enum Example
K.2 File Documentation

K.2.1 enum.h
00001 class Enum_Test
00002 {
00003 public:
00004 enum TEnum { Val1, Val2 };
00005
00006 /*! Another enum, with inline docs */
00007 enum AnotherEnum
00008 {
00009 V1, /*!< value 1 */
00010 V2 /*!< value 2 */
00011 };
00012 };
00013
00014 /*! \class Enum_Test
00015 * The class description.
00016 */
00017
00018 /*! \enum Enum_Test::TEnum
00019 * A description of the enum type.
00020 */
00021
00022 /*! \var Enum_Test::TEnum Enum_Test::Val1
00023 * The description of the first enum value.
00024 */

Appendix L
Example Example
L.1 Class Documentation

L.1.1 Example_Test Class Reference
A Example_Test class.
• void example ()
An example member function.
A Example_Test class.
More details about this class.
Examples
example_test.cpp.
example()
void Example_Test::example ( )
An example member function.
More details about this function.
Examples
example_test.cpp.
• example.cpp
L.2 Examples
L.2.1 example_test.cpp
This is an example of how to use the Example_Test class.
This is an example of how to use the Example_Test class.More details about this example.
void main()
{
Example_Test t;
t.example();
}

288 Example Example

Appendix M
Extends/Implements Example
M.1 Class Documentation

M.1.1 Car Struct Reference
Car type.
Inheritance diagram for Car:
Object
Vehicle
Car
• Vehicle base
Base class.
Protected Attributes inherited from Vehicle
• Object base
Base class.
Public Member Functions inherited from Vehicle
• void vehicleStart (Vehicle ∗obj)

• void vehicleStop (Vehicle ∗obj)
Static Public Member Functions inherited from Object
• static Object ∗ objRef (Object ∗obj)

• static Object ∗ objUnref (Object ∗obj)
Car type.
Car class.
• manual.c

290 Extends/Implements Example
M.1.2 Object Struct Reference

Object type.
Inheritance diagram for Object:
Object
Vehicle
Car Truck
Static Public Member Functions

Private Attributes
• int ref
Reference count.
Object type.
Base object class.
objRef()
static Object ∗ objRef (

Object ∗ obj ) [static]
Increments object reference count by one.
objUnref()
static Object ∗ objUnref (

Object ∗ obj ) [static]
Decrements object reference count by one.
• manual.c
M.1.3 Truck Struct Reference

Truck type.
Inheritance diagram for Truck:
Object
Vehicle
Truck

M.1 Class Documentation 291
• Vehicle base
Base class.
Protected Attributes inherited from Vehicle
• Object base
Base class.
Public Member Functions inherited from Vehicle


Truck type.
Truck class.
• manual.c
M.1.4 Vehicle Struct Reference

Vehicle type.
Inheritance diagram for Vehicle:
Object
Vehicle
Car Truck

• Object base
Base class.


292 Extends/Implements Example
Vehicle type.
Vehicle class.
vehicleStart()
void vehicleStart (
Vehicle ∗ obj )
Starts the vehicle.
vehicleStop()
void vehicleStop (
Vehicle ∗ obj )
Stops the vehicle.
• manual.c
M.2 File Documentation

M.2.1 manual.c File Reference
Classes
• struct Object
Object type.
• struct Vehicle
Vehicle type.
• struct Car
Car type.
• struct Truck
Truck type.
Functions
• int main (void)
main()
int main (
void )
Main function.
Ref vehicleStart(), objRef(), objUnref().
00083 {
00084 Car c;
00085 vehicleStart((Vehicle*) &c);
00086 }

Appendix N
File Example
N.1 File Documentation

N.1.1 file.h File Reference
A brief file description.
Variables
• int globalValue
A global integer value.
A brief file description.

A more elaborated file description.
globalValue
int globalValue [extern]

A global integer value.
More details about this value.
N.1.2 file.h
00001 /** \file file.h
00002 * A brief file description.
00003 * A more elaborated file description.
00004 */
00005
00006 /**
00007 * A global integer value.
00008 * More details about this value.
00009 */
00010 extern int globalValue;

294 File Example

Appendix O
Fn Example
O.1 Class Documentation

O.1.1 Fn_Test Class Reference
Fn_Test class.
#include <func.h>
• const char ∗ member (char, int) throw (std::out_of_range)

A member function.
Fn_Test class.
Details about Fn_Test.
member()
const char ∗ Fn_Test::member (

char c,
int n ) throw ( std::out_of_range)
A member function.
Parameters
c a character.
n an integer.
Exceptions
std::out_of_range parameter is out of range.
Returns
a character pointer.
• func.h

296 Fn Example
O.2 File Documentation

O.2.1 func.h
00001 class Fn_Test
00002 {
00003 public:
00004 const char *member(char,int) throw(std::out_of_range);
00005 };
00006
00007 const char *Fn_Test::member(char c,int n) throw(std::out_of_range) {}
00008
00009 /*! \class Fn_Test
00010 * \brief Fn_Test class.
00011 *
00012 * Details about Fn_Test.
00013 */
00014
00015 /* ! \fn const char *Fn_Test::member(char c,int n)
00016 * \brief A member function.
00017 * \param c a character.
00018 * \param n an integer.
00019 * \exception std::out_of_range parameter is out of range.
00020 * \return a character pointer.
00021 */

Appendix P
Overload Example
P.1 Class Documentation

P.1.1 Overload_Test Class Reference
A short description.
• void drawRect (int, int, int, int)

• void drawRect (const Rect &r)
A short description.
More text.
drawRect() [1/2]
void Overload_Test::drawRect (
int x,
int y,
int w,
int h )
This command draws a rectangle with a left upper corner at ( x , y ), width w and height h.
drawRect() [2/2]
void Overload_Test::drawRect (
const Rect & r )
This is an overloaded member function, provided for convenience. It differs from the above function only in what
argument(s) it accepts.
• overload.cpp

298 Overload Example

Appendix Q
Page Example
Q.1 A documentation page

Leading text.
Q.1.1 An example section

This page contains the subsections The first subsection and The second subsection. For more info see page
Another page.
The first subsection
Text.
The second subsection
More text.
Q.2 Another page

Even more info.

300 Page Example

Appendix R
Relates Example
R.1 Class Documentation

R.1.1 String Class Reference
Friends
• int strcmp (const String &, const String &)
Related Symbols
(Note that these are not member symbols.)
• void stringDebug ()
A String class.
Friends And Related Symbol Documentation
strcmp
int strcmp (
const String & s1,
const String & s2 ) [friend]
Compares two strings.
stringDebug()
void stringDebug ( ) [related]

A string debug function.
• relates.cpp

302 Relates Example

Appendix S
Author Example
S.1 Bug List

Class SomeNiceClass
Not all memory is freed when deleting an object of this class.
S.2 Class Documentation

S.2.1 SomeNiceClass Class Reference
Pretty nice class.
Pretty nice class.

This class is used to demonstrate a number of section commands.
Author
John Doe
Jan Doe
Version
4.1a
Date
1990-2011
Precondition
First initialize the system.
Bug Not all memory is freed when deleting an object of this class.
Warning
Improper use can crash your application
Copyright
GNU Public License.
• author.cpp

304 Author Example

Appendix T
Par Example
T.1 Class Documentation

T.1.1 Par_Test Class Reference
Normal text.
User defined paragraph:
Contents of the paragraph.
New paragraph under the same heading.
Note
This note consists of two paragraphs. This is the first paragraph.
And this is the second paragraph.
More normal text.

• par.cpp

306 Par Example

Appendix U
Include Example
U.1 pag_example
Our main function starts like this:
void main()
{
First we create an object t of the Include_Test class.
Include_Test t;
Then we call the example member function
t.example();
After that our little test routine ends.
}
U.2 Class Documentation

U.2.1 Include_Test Class Reference
• void example ()
a member function
A test class.
• include.cpp

Index
<![CDATA[...]]>, 218 <A NAME="...">, 209

</A>, 209 <B>, 209
</B>, 209 <BLOCKQUOTE>, 209
</BLOCKQUOTE>, 209 <BR>, 209
</CAPTION>, 209 <CAPTION>, 209
</CENTER>, 209 <CENTER>, 209
</CITE>, 209 <CITE>, 209
</CODE>, 209 <CODE>, 209
</DD>, 209 <DD>, 209
</DEL>, 209 <DEL>, 209
</DETAILS>, 209 <DETAILS>, 209
</DFN>, 209 <DFN>, 209
</DIV>, 209 <DIV>, 209
</DL>, 209 <DL>, 209
</DT>, 209 <DT>, 209
</EM>, 209 <EM>, 209
</H1>, 209 <H1>, 209
</H2>, 209 <H2>, 209
</H3>, 209 <H3>, 209
</H4>, 209 <H4>, 209
</H5>, 209 <H5>, 209
</H6>, 209 <H6>, 209
</I>, 209 <HR>, 209
</INS>, 210 <I>, 209
</KBD>, 210 <IMG SRC="...">, 210
</LI>, 210 <INS>, 210
</OL>, 210 <KBD>, 210
</P>, 210 <LI>, 210
</PRE>, 210 <OL>, 210
</S>, 210 <P>, 210
</SMALL>, 210 <PRE>, 210
</SPAN>, 210 <S>, 210
</STRIKE>, 210 <SMALL>, 210
</STRONG>, 210 <SPAN>, 210
</SUB>, 210 <STRIKE>, 210
</SUP>, 210 <STRONG>, 210
</TABLE>, 210 <SUB>, 210
</TBODY>, 210 <SUP>, 210
</TD>, 210 <TABLE>, 210
</TFOOT>, 210 <TBODY>, 210
</TH>, 210 <TD>, 210
</THEAD>, 210 <TFOOT>, 210
</TR>, 210 <TH>, 210
</TT>, 210 <THEAD>, 210
</U>, 210 <TR>, 210
</UL>, 210 <TT>, 210
</VAR>, 210 <U>, 210
<A HREF="...">, 209 <UL>, 210
<A ID="...">, 209 <VAR>, 210

INDEX 309
<c>, 217 \cite, 187

<code>, 217 \class, 163
<description>, 217 \code, 196
<example>, 217 \concept, 164
<exception>, 217 \cond, 177
<include>, 217 \copybrief, 197
<inheritdoc>, 217 \copydetails, 197
<item>, 217 \copydoc, 196
<list>, 217 \copyright, 178
<listheader>, 217 \date, 178
<para>, 217 \def, 164
<param>, 217 \defgroup, 164
<paramref>, 217 \deprecated, 180
<permission>, 217 \details, 180
<remarks>, 217 \diafile, 200
<returns>, 217 \dir, 164
<see>, 217 \docbookinclude, 194
<seealso>, 217 \docbookonly, 197
<summary>, 217 \dontinclude, 190
<term>, 218 \dot, 197
<typeparam>, 218 \dotfile, 200
<typeparamref>, 218 \doxyconfig, 201
<value>, 218 \e, 201
__init__ \else, 181
docstring.PyClass, 278 \elseif, 181
_memVar \em, 201
docstring.PyClass, 278 \endcode, 201
\<, 207 \endcond, 181
\>, 207 \enddocbookonly, 202
\--, 208 \enddot, 202
\---, 208 \endhtmlonly, 202
\., 207 \endif, 181
\::, 208 \endinternal, 166
\=, 208 \endlatexonly, 202
\@, 207 \endlink, 188
\", 207 \endmanonly, 202
\#, 207 \endmsc, 202
\$, 207 \endparblock, 184
\%, 207 \endrtfonly, 202
\&, 207 \endsecreflist, 188
\∼, 207 \enduml, 202
\\, 206 \endverbatim, 202
\|, 208 \endxmlonly, 203
\a, 195 \enum, 165
\addindex, 187 \example, 165
\addtogroup, 161 \exception, 181
\anchor, 187 \extends, 166
\arg, 195 \f(, 203
\attention, 176 \f), 203
\author, 176 \f$, 203
\authors, 177 \f{, 203
\b, 196 \f[, 203
\brief, 177 \f], 203
\bug, 177 \f}, 204
\c, 196 \file, 166
\callergraph, 162 \fileinfo, 167
\callgraph, 161 \fn, 167
\category, 163 \headerfile, 168

310 INDEX
\hidecallergraph, 162 \ref, 188

\hidecallgraph, 161 \refitem, 188
\hideinitializer, 168 \related, 175
\hiderefby, 162 \relatedalso, 175
\hiderefs, 163 \relates, 174
\htmlinclude, 194 \relatesalso, 175
\htmlonly, 204 \remark, 184
\idlexcept, 168 \remarks, 185
\if, 181 \result, 185
\ifnot, 182 \return, 185
\image, 204 \returns, 185
\implements, 168 \retval, 185
\include, 191 \rtfinclude, 194
\includedoc, 192 \rtfonly, 206
\includelineno, 191 \sa, 185
\ingroup, 169 \secreflist, 188
\interface, 169 \section, 189
\internal, 169 \see, 185
\invariant, 182 \short, 185
\latexinclude, 194 \showdate, 178
\latexonly, 205 \showinitializer, 175
\li, 205 \showrefby, 162
\line, 192 \showrefs, 163
\lineinfo, 167 \since, 185
\link, 188 \skip, 192
\mainpage, 169 \skipline, 192
\maninclude, 194 \snippet, 192
\manonly, 205 \snippetdoc, 193
\memberof, 170 \snippetlineno, 193
\msc, 198 \startuml, 199
\mscfile, 200 \static, 175
\n, 206 \struct, 175
\name, 171 \subpage, 188
\namespace, 171 \subsection, 189
\noop, 180 \subsubsection, 190
\nosubgrouping, 171 \tableofcontents, 189
\note, 183 \test, 186
\overload, 171 \throw, 186
\p, 206 \throws, 186
\package, 172 \todo, 186
\page, 172 \tparam, 184
\par, 183 \typedef, 175
\paragraph, 190 \union, 176
\param, 183 \until, 193
\parblock, 184 \var, 176
\post, 184 \verbatim, 206
\pre, 184 \verbinclude, 193
\private, 173 \version, 186
\privatesection, 173 \vhdlflow, 176
\property, 173 \warning, 186
\protected, 173 \weakgroup, 176
\protectedsection, 173 \xmlinclude, 195
\protocol, 174 \xmlonly, 206
\public, 174 \xrefitem, 187
\publicsection, 174 ∼Autolink_Test
\pure, 174 Autolink_Test, 244
\qualifier, 163 ∼Javadoc_Test
\raisewarning, 180 Javadoc_Test, 269

INDEX 311
∼QTstyle_Test C3, 261

QTstyle_Test, 267 C4, 261
C5, 262
A, 249 CALL_GRAPH, 153
m_self, 250 CALLER_GRAPH, 153
memgrp.cpp, 264 Car, 289
A documentation page, 299 CASE_SENSE_NAMES, 124
ABBREVIATE_BRIEF, 119 CHM_FILE, 137
ABS CHM_INDEX_ENCODING, 137
autolink.cpp, 245 CITE_BIB_FILES, 127
define.h, 283 CLANG_ADD_INC_PATHS, 131
acknowledgments, 5 CLANG_ASSISTED_PARSING, 131
add CLANG_DATABASE_PATH, 132
restypedef.cpp, 248 CLANG_OPTIONS, 131
Afterdoc_Test, 265 CLASS_GRAPH, 152
EnumType, 265 close
EVal1, 265 structcmd.h, 274
EVal2, 265 cmake, 7, 9
value, 265 COLLABORATION_GRAPH, 152
ALIASES, 120 COMPACT_LATEX, 143
ALLEXTERNALS, 151 COMPACT_RTF, 146
ALLOW_UNICODE_NAMES, 118 Configuration, 115
ALPHABETICAL_INDEX, 132 Coord
ALWAYS_DETAILED_SEC, 119 restypedef.cpp, 248
Another page, 299 CoordStruct, 247
AnotherEnum x, 247
Enum_Test, 285 y, 247
autolink.cpp, 244 CPP_CLI_SUPPORT, 122
ABS, 245 CREATE_SUBDIRS, 118
B, 245 CREATE_SUBDIRS_LEVEL, 118
GlobEnum, 245 cstyle
globVar, 246 javadoc-banner.h, 270
GVal1, 245 Custom Commands, 83
GVal2, 245 Customizing the output, 75
AUTOLINK_SUPPORT, 121
Autolink_Test, 243 D, 252
∼Autolink_Test, 244 m_c, 253
Autolink_Test, 244 define.h, 283
EType, 244 ABS, 283
member, 244 MAX, 283
Val1, 244 MIN, 283
Val2, 244 DIA_PATH, 154
Automatic link generation, 61 DIAFILE_DIRS, 154
diagrams_a.h, 255
B, 250 diagrams_b.h, 255
autolink.cpp, 245 diagrams_c.h, 256
m_a, 250 diagrams_d.h, 256
memgrp.cpp, 264 diagrams_e.h, 258
BINARY_TOC, 137 DIR_GRAPH_MAX_DEPTH, 153
bison, 7, 9 DIRECTORY_GRAPH, 153
BRIEF_MEMBER_DESC, 119 DISABLE_INDEX, 138
browser, 14 DISTRIBUTE_GROUP_DOC, 122
Bug List, 303 Doc++, 5
BUILTIN_STL_SUPPORT, 121 docbook, 15
DOCBOOK_OUTPUT, 148
C, 251 DOCSET_BUNDLE_ID, 136
m_d, 251 DOCSET_FEEDNAME, 136
C1, 261 DOCSET_FEEDURL, 136
C2, 261 DOCSET_PUBLISHER_ID, 136

312 INDEX
DOCSET_PUBLISHER_NAME, 136 example

docstring, 277 Example_Test, 287
func, 277 EXAMPLE_PATH, 129
docstring.py, 278 EXAMPLE_PATTERNS, 129
docstring.PyClass, 277 EXAMPLE_RECURSIVE, 129
__init__, 278 Example_Test, 287
_memVar, 278 example, 287
PyMethod, 278 EXCLUDE, 129
Documenting the code, 17 EXCLUDE_PATTERNS, 129
DOT_CLEANUP, 155 EXCLUDE_SYMBOLS, 129
DOT_COMMON_ATTR, 151 EXCLUDE_SYMLINKS, 129
DOT_EDGE_ATTR, 151 EXPAND_AS_DEFINED, 150
DOT_FONTPATH, 152 EXPAND_ONLY_PREDEF, 150
DOT_GRAPH_MAX_NODES, 154 EXT_LINKS_IN_WINDOW, 139
DOT_IMAGE_FORMAT, 154 EXTENSION_MAPPING, 121
DOT_MULTI_TARGETS, 155 External Indexing and Searching, 69
DOT_NODE_ATTR, 152 EXTERNAL_GROUPS, 151
DOT_NUM_THREADS, 151 EXTERNAL_PAGES, 151
DOT_PATH, 154 EXTERNAL_SEARCH, 141
DOT_UML_DETAILS, 152 EXTERNAL_SEARCH_ID, 142
DOT_WRAP_THRESHOLD, 153 EXTRA_PACKAGES, 143
DOTFILE_DIRS, 154 EXTRA_SEARCH_MAPPINGS, 142
DOXYFILE_ENCODING, 118 EXTRACT_ALL, 123
Doxygen usage, 101 EXTRACT_ANON_NSPACES, 123
Doxygen's Internals, 237 EXTRACT_LOCAL_CLASSES, 123
doxygenBanner EXTRACT_LOCAL_METHODS, 123
javadoc-banner.h, 271 EXTRACT_PACKAGE, 123
Doxywizard usage, 103 EXTRACT_PRIV_VIRTUAL, 123
drawRect EXTRACT_PRIVATE, 123
Overload_Test, 297 EXTRACT_STATIC, 123
E, 253 Features, 99
ECLIPSE_DOC_ID, 138 features, 99
Emoji support, 219 file.h, 293
ENABLE_PREPROCESSING, 149 globalValue, 293
ENABLED_SECTIONS, 126 FILE_PATTERNS, 129
Enum_Test, 285 FILE_VERSION_FILTER, 126
AnotherEnum, 285 FILTER_PATTERNS, 130
TEnum, 285 FILTER_SOURCE_FILES, 130
V1, 285 FILTER_SOURCE_PATTERNS, 130
V2, 285 flex, 7, 9
Val1, 285 Fn_Test, 295
ENUM_VALUES_PER_LINE, 139 member, 295
enumPtr FORCE_LOCAL_INCLUDES, 125
Javadoc_Test, 270 FORMULA_FONTSIZE, 139
QTstyle_Test, 268 FORMULA_MACROFILE, 140
EnumType FORTRAN_COMMENT_AFTER, 130
Afterdoc_Test, 265 Frequently Asked Questions, 87
enumVar FULL_PATH_NAMES, 119
Javadoc_Test, 270 FULL_SIDEBAR, 139
QTstyle_Test, 268 func
errno docstring, 277
structcmd.h, 275 pyexample, 278
EType func1InGroup1
Autolink_Test, 244 Memgrp_Test, 263
EVal1 func1InGroup2
Afterdoc_Test, 265 Memgrp_Test, 263
EVal2 func2InGroup1
Afterdoc_Test, 265 Memgrp_Test, 263

INDEX 313
func2InGroup2 HTML_COLORSTYLE_GAMMA, 135

Memgrp_Test, 264 HTML_COLORSTYLE_HUE, 135
HTML_COLORSTYLE_SAT, 135
GENERATE_AUTOGEN_DEF, 148 HTML_DYNAMIC_MENUS, 135
GENERATE_BUGLIST, 126 HTML_DYNAMIC_SECTIONS, 136
GENERATE_CHI, 137 HTML_EXTRA_FILES, 135
GENERATE_DEPRECATEDLIST, 126 HTML_EXTRA_STYLESHEET, 134
GENERATE_DOCBOOK, 148 HTML_FILE_EXTENSION, 132
GENERATE_DOCSET, 136 HTML_FOOTER, 134
GENERATE_ECLIPSEHELP, 138 HTML_FORMULA_FORMAT, 139
GENERATE_HTML, 132 HTML_HEADER, 132
GENERATE_HTMLHELP, 137 HTML_INDEX_NUM_ENTRIES, 136
GENERATE_LATEX, 142 HTML_OUTPUT, 132
GENERATE_LEGEND, 155 HTML_STYLESHEET, 134
GENERATE_MAN, 147
GENERATE_PERLMOD, 149 IDL_PROPERTY_SUPPORT, 122
GENERATE_QHP, 137 IGNORE_PREFIX, 132
GENERATE_RTF, 146 IMAGE_PATH, 129
GENERATE_SQLITE3, 148 INCLUDE_FILE_PATTERNS, 150
GENERATE_TAGFILE, 151 INCLUDE_GRAPH, 153
GENERATE_TESTLIST, 126 INCLUDE_PATH, 150
GENERATE_TODOLIST, 125 Include_Test, 307
GENERATE_TREEVIEW, 139 INCLUDED_BY_GRAPH, 153
GENERATE_XML, 147 Including formulas, 49
Getting started, 11 Including tables, 51
glob_func INHERIT_DOCS, 120
memgrp.cpp, 264 INLINE_GROUPED_CLASSES, 122
globalValue INLINE_INFO, 125
file.h, 293 INLINE_INHERITED_MEMB, 119
GlobEnum INLINE_SIMPLE_STRUCTS, 122
autolink.cpp, 245 INLINE_SOURCES, 130
globVar INPUT, 128
autolink.cpp, 246 INPUT_ENCODING, 128
GPL, 4 INPUT_FILE_ENCODING, 128
GRAPHICAL_HIERARCHY, 153 INPUT_FILTER, 129
Graphs and diagrams, 53 Installation, 7
group.cpp, 262 installation, 7
GROUP_GRAPHS, 152 INTERACTIVE_SVG, 154
GROUP_NESTED_COMPOUNDS, 122 INTERNAL_DOCS, 124
Grouping, 43 Internationalization, 223
GVal1 Introduction, 3
autolink.cpp, 245
GVal2 javadoc-banner.h, 270
autolink.cpp, 245 cstyle, 270
doxygenBanner, 271
handler javadocBanner, 271
Javadoc_Test, 270 JAVADOC_AUTOBRIEF, 119
QTstyle_Test, 268 JAVADOC_BANNER, 119
HAVE_DOT, 151 Javadoc_Test, 268
HHC_LOCATION, 137 ∼Javadoc_Test, 269
HIDE_COMPOUND_REFERENCE, 124 enumPtr, 270
HIDE_FRIEND_COMPOUNDS, 124 enumVar, 270
HIDE_IN_BODY_DOCS, 124 handler, 270
HIDE_SCOPE_NAMES, 124 Javadoc_Test, 269
HIDE_UNDOC_CLASSES, 124 publicVar, 270
HIDE_UNDOC_MEMBERS, 124 TEnum, 269
HIDE_UNDOC_RELATIONS, 151 testMe, 269
HTML Commands, 209 testMeToo, 269
HTML_COLORSTYLE, 135 TVal1, 269

314 INDEX
TVal2, 269 Fn_Test, 295

TVal3, 269 memgrp.cpp, 264
javadocBanner A, 264
javadoc-banner.h, 271 B, 264
glob_func, 264
LaTeX, 14 Memgrp_Test, 263
LATEX_BATCHMODE, 146 func1InGroup1, 263
LATEX_BIB_STYLE, 146 func1InGroup2, 263
LATEX_CMD_NAME, 142 func2InGroup1, 263
LATEX_EMOJI_DIRECTORY, 146 func2InGroup2, 264
LATEX_EXTRA_FILES, 145 ungroupedFunction, 264
LATEX_EXTRA_STYLESHEET, 145 MIN
LATEX_FOOTER, 145 define.h, 283
LATEX_HEADER, 143 MSCFILE_DIRS, 155
LATEX_HIDE_INDICES, 146 MSCGEN_TOOL, 155
LATEX_MAKEINDEX_CMD, 142 MULTILINE_CPP_IS_BRIEF, 120
LATEX_OUTPUT, 142 mux.vhdl, 280
LAYOUT_FILE, 127 mux_using_with, 279
libiconv, 7 mux_using_with.behavior, 280
license, 4
Linking to external documentation, 85 N1, 261
Lists, 41 NUM_PROC_THREADS, 123
LOOKUP_CACHE_SIZE, 122
OBFUSCATE_EMAILS, 139
m_a Object, 290
B, 250 objRef, 290
m_c objUnref, 290
D, 253 objRef
m_d Object, 290
C, 251 objUnref
m_self Object, 290
A, 250 open
MACRO_EXPANSION, 149 structcmd.h, 274
main OPTIMIZE_FOR_FORTRAN, 120
manual.c, 292 OPTIMIZE_OUTPUT_FOR_C, 120
make, 7 OPTIMIZE_OUTPUT_JAVA, 120
MAKEINDEX_CMD_NAME, 142 OPTIMIZE_OUTPUT_SLICE, 121
man, 15 OPTIMIZE_OUTPUT_VHDL, 121
MAN_EXTENSION, 147 Output Formats, 65
MAN_LINKS, 147 output formats, 65
MAN_OUTPUT, 147 OUTPUT_DIRECTORY, 118
MAN_SUBDIR, 147 OUTPUT_LANGUAGE, 118
manual.c, 292 Overload_Test, 297
main, 292 drawRect, 297
Markdown support, 29
MARKDOWN_ID_STYLE, 121 pag_example, 307
MARKDOWN_SUPPORT, 121 PAPER_TYPE, 143
MATHJAX_CODEFILE, 140 Par_Test, 305
MATHJAX_EXTENSIONS, 140 parsing, 15
MATHJAX_FORMAT, 140 PDF_HYPERLINKS, 145
MATHJAX_RELPATH, 140 Perl Module Output, 229
MATHJAX_VERSION, 140 perlmod, 229
MAX PERLMOD_LATEX, 149
define.h, 283 PERLMOD_MAKEVAR_PREFIX, 149
structcmd.h, 273 PERLMOD_PRETTY, 149
MAX_DOT_GRAPH_DEPTH, 155 PLANTUML_CFG_FILE, 154
MAX_INITIALIZER_LINES, 126 PLANTUML_INCLUDE_PATH, 154
member PLANTUML_JAR_PATH, 154
Autolink_Test, 244 PREDEFINED, 150

INDEX 315
Preprocessing, 57 SEARCH_INCLUDES, 150

PROJECT_BRIEF, 118 SEARCHDATA_FILE, 141
PROJECT_LOGO, 118 SEARCHENGINE, 141
PROJECT_NAME, 118 SEARCHENGINE_URL, 141
PROJECT_NUMBER, 118 Searching, 67
publicVar SEPARATE_MEMBER_PAGES, 120
Javadoc_Test, 270 SERVER_BASED_SEARCH, 141
QTstyle_Test, 268 SHORT_NAMES, 119
pyexample, 278 SHOW_FILES, 126
func, 278 SHOW_GROUPED_MEMB_INC, 125
pyexample.PyClass, 279 SHOW_HEADERFILE, 124
PyMethod, 279 SHOW_INCLUDE_FILES, 124
PyMethod SHOW_NAMESPACES, 126
docstring.PyClass, 278 SHOW_USED_FILES, 126
pyexample.PyClass, 279 SIP_SUPPORT, 122
python, 7, 9 SITEMAP_URL, 137
PYTHON_DOCSTRING, 120 SKIP_FUNCTION_MACROS, 150
SomeNiceClass, 303
QCH_FILE, 138 SORT_BRIEF_DOCS, 125
QHG_LOCATION, 138 SORT_BY_SCOPE_NAME, 125
QHP_CUST_FILTER_ATTRS, 138 SORT_GROUP_NAMES, 125
QHP_CUST_FILTER_NAME, 138 SORT_MEMBER_DOCS, 125
QHP_NAMESPACE, 138 SORT_MEMBERS_CTORS_1ST, 125
QHP_SECT_FILTER_ATTRS, 138 SOURCE_BROWSER, 130
QHP_VIRTUAL_FOLDER, 138 SOURCE_TOOLTIPS, 131
Qt, 7 Special Commands, 159
QT_AUTOBRIEF, 120 SQLITE3_OUTPUT, 148
QTstyle_Test, 266 SQLITE3_RECREATE_DB, 149
∼QTstyle_Test, 267 strcmp
enumPtr, 268 String, 301
enumVar, 268 STRICT_PROTO_MATCHING, 125
handler, 268 String, 301
publicVar, 268 strcmp, 301
QTstyle_Test, 267 stringDebug, 301
TEnum, 266 stringDebug
testMe, 267 String, 301
testMeToo, 267 STRIP_CODE_COMMENTS, 130
TVal1, 267 STRIP_FROM_INC_PATH, 119
TVal2, 267 STRIP_FROM_PATH, 119
TVal3, 267 structcmd.h, 273
QUIET, 127 close, 274
errno, 275
read MAX, 273
structcmd.h, 274 open, 274
RECURSIVE, 129 read, 274
REFERENCED_BY_RELATION, 130 UINT32, 274
REFERENCES_LINK_SOURCE, 131 write, 274
REFERENCES_RELATION, 130 SUBGROUPING, 122
REPEAT_BRIEF, 119
RESOLVE_UNNAMED_PARAMS, 124 TAB_SIZE, 120
restypedef.cpp, 247 TAGFILES, 150
add, 248 TEMPLATE_RELATIONS, 153
Coord, 248 TEnum
RTF, 14 Enum_Test, 285
RTF_EXTENSIONS_FILE, 147 Javadoc_Test, 269
RTF_HYPERLINKS, 146 QTstyle_Test, 266
RTF_OUTPUT, 146 Test, 281
RTF_STYLESHEET_FILE, 147 testMe
Javadoc_Test, 269

316 INDEX
QTstyle_Test, 267 WARN_IF_DOC_ERROR, 127

testMeToo WARN_IF_INCOMPLETE_DOC, 127
Javadoc_Test, 269 WARN_IF_UNDOC_ENUM_VAL, 127
QTstyle_Test, 267 WARN_IF_UNDOCUMENTED, 127
The Fifth Group, 260 WARN_LINE_FORMAT, 128
The First Group, 259 WARN_LOGFILE, 128
The Fourth Group, 260 WARN_NO_PARAMDOC, 127
The Second Group, 259 WARNINGS, 127
The Third Group, 260 write
TIMESTAMP, 123 structcmd.h, 274
TOC_EXPAND, 137
TOC_INCLUDE_HEADINGS, 121 x
TREEVIEW_WIDTH, 139 CoordStruct, 247
Troubleshooting, 93 XML, 15
Truck, 290 XML Commands, 217
TVal1 XML_NS_MEMB_FILE_SCOPE, 148
Javadoc_Test, 269 XML_OUTPUT, 148
QTstyle_Test, 267 XML_PROGRAMLISTING, 148
TVal2
Javadoc_Test, 269 y
QTstyle_Test, 267 CoordStruct, 247
TVal3
Javadoc_Test, 269
QTstyle_Test, 267
TYPEDEF_HIDES_STRUCT, 122
UINT32
structcmd.h, 274
UML_LIMIT_NUM_FIELDS, 152
UML_LOOK, 152
ungroupedFunction
Memgrp_Test, 264
USE_HTAGS, 131
USE_MATHJAX, 140
USE_MDFILE_AS_MAINPAGE, 130
USE_PDFLATEX, 146
V1
Enum_Test, 285
V2
Enum_Test, 285
Val1
Autolink_Test, 244
Enum_Test, 285
Val2
Autolink_Test, 244
value
Afterdoc_Test, 265
Vehicle, 291
vehicleStart, 292
vehicleStop, 292
vehicleStart
Vehicle, 292
vehicleStop
Vehicle, 292
VERBATIM_HEADERS, 131
WARN_AS_ERROR, 127
WARN_FORMAT, 128

Doxygen Manual-1.9.7

Uploaded by

Document Informationclick to expand document information

Copyright:

Available Formats

Doxygen Manual-1.9.7

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Doxygen Manual-1.9.7

Uploaded by

Copyright:

Available Formats

Manual for version @VERSION@

Written by Dimitri van Heesch

4 Documenting the code 17

Generated by Doxygen @VERSION@

5.1 Standard Markdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Generated by Doxygen @VERSION@

10 Graphs and diagrams 53

12 Automatic link generation 61

15 Customizing the output 75

17 Linking to external documentation 85

Generated by Doxygen @VERSION@

18 Frequently Asked Questions 87

21 Doxygen usage 101

22 Doxywizard usage 103

Generated by Doxygen @VERSION@

22.1.4 Diagrams to generate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

24 Special Commands 159

Generated by Doxygen @VERSION@

24.11 \qualifier <label> | ¨(text)¨ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Generated by Doxygen @VERSION@

24.51 \related <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Generated by Doxygen @VERSION@

24.91 \remark { remark text } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

Generated by Doxygen @VERSION@

24.131 \snippetlineno <file-name> ( block_id ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Generated by Doxygen @VERSION@

24.171 \f$ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

25 HTML Commands 209

26 XML Commands 217

27 Emoji support 219

Generated by Doxygen @VERSION@

27.1 Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

III Developers Manual 221

29 Perl Module Output 229

30 Doxygen's Internals 237

A Autolink Example 243

B Resolving Typedef Example 247

Generated by Doxygen @VERSION@

Detailed Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

C Diagrams Example 249

D Modules Example 259

Generated by Doxygen @VERSION@

D.3.1 C1 Class Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

E Member Groups Example 263

F Style Examples 265

Generated by Doxygen @VERSION@

G Structural Commands Example 273

H Language Examples 277

I Class Example 281

J Define Example 283

Generated by Doxygen @VERSION@

Macro Definition Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

K Enum Example 285

L Example Example 287

M Extends/Implements Example 289

N File Example 293

Generated by Doxygen @VERSION@

P Overload Example 297