Doxygen 的图表 dot

最新推荐文章于 2025-03-07 18:21:10 发布

napu_sh

最新推荐文章于 2025-03-07 18:21:10 发布

阅读量2.5k

点赞数 1

分类专栏：工程文章标签： documentation javadoc file output postscript whitespace

工程专栏收录该内容

35 篇文章

订阅专栏

转自http://hi.baidu.com/zhmsong/blog/category/Doxygen

1。Doxygen 的图表 dot

图表

Doxygen里有内置生成C++类层次图的功能。它使用贝尔实验室开发的graphviz 1.5中的工具"dot"来生成更高级的图表。使用这个工具时，要将配置选项HAVE_DOT设为YES。

* 当GRAPHICAL_HIERARCHY设置为YES时，将会绘制一个图形表示的类图结构。
* 当CLASS_GRAPH设置为YES时，会为每个归档的类创建一张图表示其直接或间接的继承关系。
* 当INCLUDE_GRAPH设置为YES时，会为每个归档文件创建一幅包含依赖图，此功能目前仅有HTML和RTF格式支持。
* 当COLLABORATION_GRAPH设置为YES时，会为每个归档类或结构绘制基类继承关系图和使用关系图。
* 当CALL_GRAPH设置为YES时，会为每个函数显示一幅直接或间接调用关系图。

更具体的信息可以参考Doxygen的手册。

2. Doxygen入门（1）--基础知识

来自：http://www.stack.nl/~dimitri/doxygen/starting.html

Getting started

The executable doxygen is the main program that parses the sources and generates the documentation. See section Doxygen usage for more detailed usage information.

[可执行的 doxygen 是一种源文件转换及文档生成工具，具体使用信息请参见 Doxygen用法 ]

The executable doxytag is only needed if you want to generate references to external documentation (i.e. documentation that was generated by doxygen) for which you do not have the sources. See section Doxytag usage for more detailed usage information.

[可执行的 doxytag 是一种外部文档索引生成工具，当然所谓外部文档也是应由 doxygen 生成的，doxytag 特别适合于所基于的外部文档不包含源程序时的情况。具体查看 Doxytag 用法 ]

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.

[另外，可执行的 doxywizard 是一种前端图形工具，用于配置文件的编辑。如果在 Mac 中使用 doxywizard 可以直接点击 Doxygen 应用程序图标。]

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):

[下图说明了工具和信息流向的关系，虽然看起来有些复杂，但其实很简单，当然复杂也是因为 Doxygen 期望能够提供更完善的功能。]

Doxygen information flow

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.

[Doxygen 使用配置文件来决定使用中所有的设置。每个项目应该拥有自己的配置文件。这里所说的项目可以包含一个文件的项目，当然更适合的是包括整个源文件树中所有文件的项目。]

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 提供了配置模板，使用如下命令即可：]

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 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.

[其中 <config-file> 是配置文件的名称。如果忽略该项，默认的文件名将被创建，即 Doxyfile。如果指定的 <config-file> 已经存在，doxygen 将重命名原来的文件为 <config-file>.bak，之后再生成新的配置模板。如果我们使用 -（减号）作为文件名，doxygen 将尝试从标准输入（stdin）读取配置信息，这种方式特别适合于自写脚本。]

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:

[配置文件的格式类似于简单的 Makefile，它包含一些具有赋值格式的标签，如下：]

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 config 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.

[如果我们不希望以文本形式编辑配置文件，我们可以使用 doxywizard，它是一个 doxygen 的前端 gui，用以创建、读取、编辑 doxygen 配置文件，可以通过对话框选择配置选项。]

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.

[对于只包含几个C或C++源文件及头文件的小项目来说，我们可以使 INPUT 标签留空，这样 doxygen 将在当前文件夹中搜寻所有的源文件。]

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 source extensions is used). 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:

[如果处理包含一个源文件目录的大项目，我们应该令 INPUT 标签等于源文件根目录和相应的目录，并添加文件类型
标签 FILE_PATTERNS  （如 *.cpp、*.h）。只有匹配文件类型的文件才会被处理，如果该标签忽略不指明，则“源文件
扩展列表”将被采用。如果希望迭代处理源代码树，你必须设置 RECURSIVE  为 YES。如果希望更精确地控制文件
类型列表，还可以使用 EXCLUDE 和 EXCLUDE_PATTERNS  。如下面列子，如果需要忽略掉 test 目录下的所有文件，
可以这样处理：]

EXCLUDE_PATTERNS = */test/*

Doxygen looks at the file's extension to determine how to parse a file. If a file has an .idl or .odl extension it is treated as an IDL file. If it has a .java extension it is treated as a file written in Java. Files ending with .cs are treated as C# files and the .pyextension selects the Python parser. Finally, files with the extensions .php, .php4, .inc or .phtml are treated as PHP sources. Any other extension is parsed as if it is a C/C++ file, where files that end with .m are treated as Objective-C source files.

[Doxygen 是通过文件的扩展名来决定如何处理文件的。如果某个文件扩展名为 .idl 或 .odl，那么这个文件即被认为

是 IDL 文件。如果某个具有 .java 扩展名，那么即被认为是由 Java 语言写成的文件。同样，.cs 是 C# 文件，.py 文件

作为 Python 来处理；.php、.php4、.inc 或 .phtml 被认为是 PHP 源文件。其他的就被认为是 C/C++文件处理，其中

以 .m 结尾的被认为是 Object-C 文件处理。]

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 as long as EXTRACT_ALL is set to YES.

[如果你使用 doxygen 对现有项目进行处理（也就是说目前 doxygen 对要处理的项目还一无所知），我们可以先规划出未来成品的结构如何，或者是明确到底以什么样子呈现。为实现该目的，我们必须设置 EXTRACT_ALL 标签为 YES。这样，doxygen 将记录源文件中所有内容。请注意：使用了该标签后，未记录的成员或文件内容将不会得到任何提示或警告。]

To analyse 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).

[另外，使用交叉引用（链接源文件定义片断）在软件分析中十分有效，Doxygen 将在 SOURCE_BROWSER 为 YES 的情况下自动产生交叉引用。如果设置 INLINE_SOURCES 为 YES，可以使源代码直接加入到文档中，这对代码复审非常有用。]

(自己注：记得将 OUTPUT_LANGUAGE=Chinese)

Step 2: Running doxygen [第二步：运行 doxygen]

To generate the documentation you can now enter: [我们可以直接使用以下命令产生文档：]

doxygen <config-file>

Depending on your settings doxygen will create html, rtf, latex, xml and/or man directories inside the output directory. As the names suggest these directories contain the generated documentation in HTML, RTF, $/mbox{/LaTeX}$ , XML and Unix-Man page format.

[通过不同的设置，doxygen 可以在输出目录中生成各种文件夹，如何 html、rtf、latex、xml 或 man等，并分别代表所生成的 HTML、RTF、XML以及 $/mbox{/LaTeX}$ , Unix-Man 格式文档。]

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, and MAN_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).

[默认的输出文件夹为当前运行 doxygen 的文件夹，当然可以使用 OUTPUT_DIRECTORY 修改根目录。另外，根目录下特定的文件夹可以通过以下标签设置，即HTML_OUTPUT, RTF_OUTPUT, LATEX_OUTPUT, XML_OUTPUT, 和 MAN_OUTPUT 。如果输出文件夹不存在，那么 doxygen 将尝试创建一个新的，但是不会象 mkdir -p 一样工作。]

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, Safari, Konqueror, and sometimes IE6 to test the generated output).

[生成的 HTML 文档通过 index.html 起始，这些 HTML 文档采用 CSS。]

Some of the features the HTML section (such as GENERATE_TREEVIEW) require a browser that supports DHTML and Javascript.

[还有一些特性（如 GENERATE_TREEVIEW）需要浏览器支持 DHTML 和 Javascript。]

If you plan to use the search engine (see SEARCHENGINE), you should view the HTML output via a PHP-enabled web server (e.g. apache with the PHP module installed).

[如果你计划使用搜索引擎（见SEARCHENGINE）你应当通过 php web服务器来查看 html 输出。]

LaTeX output

The generated $/mbox{/LaTeX}$

documentation must first be compiled by a $/mbox{/LaTeX}$

compiler (I use a recent teTeX distribution). To simplify the process of compiling the generated documentation, doxygen writes a Makefile into the latex directory.

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.

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 field. 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).

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 produced by doxygen in an incremental way (see addon/doxmlparser/include/doxmlintf.h for the interface of the library)

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.

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 as well.

[虽然标记源文件放在了第三步，但实际上对于一个新项目来说，这应该是第一步。这里我们假设你已经有一些代码，并想利用 doxygen 来生成漂亮的文档以描述 API 或内部细节等。]

If the EXTRACT_ALL option is set to NO in the configuration file (the default), then doxygen will only generate documentation for documented members, files, classes and namespaces. So how do you document these? For members, classes and namespaces there are basically two options:

[如果 EXTRACT_ALL 标签设置为 NO（默认值），那么 doxygen 只生成已经标记的成员、文件、类及命名空间。所以我们该如何标记它们，这里对成员、类、命名空间给出两条基本原则：]

- Place a special documentation block in front of the declaration or definition of the member, class or namespace. For file, class and namespace members it is also allowed to place the documention directly after the member. See section Special documentation blocks to learn more about special documentation blocks.
- 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.

1、在成员、类、命名空间前放置特别的标记块。对于一个文件、类、命名空间等，同样可以直接在成员后面加上标记。详见 Special documentation blocks。
2、在另一个文件或位置放置特别的标记块，并在标记块中置入结构化命令。结构化命令将提供到某个记录块或某个位置的链接（如链接到成员、类、命名空间等。）详见： Documentation at other places

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, variable, typedefs, defines) do not need an explicit structural command; just putting a special documentation block in front or behind them will do.

[文件只能以上面第二种方式标记，因为我们是没有方式在一个文件前面置入标记块的。当然，文件成员（包括函数、变量、类型定义、定义等）不需要明确的结构化命令。只要在它们前面或后面放入特别的标记块即可。]

The text inside a special documentation block is parsed before it is written to the HTML and/or $/mbox{/LaTeX}$ output files.

[特别标记块中的文本将在输出前被转换。]

During parsing the following steps take place: [转换步骤：]

- The special commands inside the documentation are executed. See section Special Commands for an overview of all commands.
- [标记中的特别命令被执行，详见： Special Commands ]
- If a line starts with some whitespace followed by one or more asterisks (*) and then optionally more whitespace, then all whitespace and asterisks are removed.
- [如果某行以 whitespace 加上一个或多个星号开始，后面可能还会有更多 whitespace，那么所有的 whitespace 和星号将被删除]
- 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.
- [创建标记成员的链接。详见：Automatic link generation ]
- HTML tags that are in the documentation are interpreted and converted to equivalents for the output. See section HTML Commands for an overview of all supported HTML tags.
- [文档中的HTML标签被转换。]

Go to the next section or return to the index.

3. Doxygen入门（2）--代码标记方法

来自：http://www.stack.nl/%7Edimitri/doxygen/docblocks.html#specialblock

Documenting the code [标记代码]

Special documentation blocks [特别标记块]

A special documentation block is a C or C++ style comment block with some additional markings, so doxygen knows it is a piece of documentation that needs to end up in the generated documentation. For Python and VHDL code there are a different comment conventions, which can be found in section Special documentation blocks in Python and Special documentation blocks in VHDL respectively.

[特别标记块属于带附加标记的 C 或 C++ 风格的注释块，所以 doxygen 才能够判断出它是程序文档的一部分。对于Python 和 VHDL 代码来说，因为它们有不同的注释方法，所以请另行参考 Special documentation blocks in Python 和 Special documentation blocks in VHDL 。]

For each code item there are two (or in some cases three) types of descriptions, which together form the documentation: 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).

[Doxygen 允许存在多个简要描述或详细描述，但我们不推荐这样做，因为各种描述出现的顺序将变得模糊不定。]

As the name suggest, a brief description is a short one-liner, whereas the detailed description provides longer, more detailed documentation. An "in body" description can also act as a detailed description or can describe a collection of implementation details. For the HTML output brief descriptions are also use to provide tooltips at places where an item is referenced.

[如名称所显示的，简要描述是一种短小精悍的一句话，而详细描述则提供了较为详尽的文档。“体内式”描述可以被看作是详细描述，它通常描述了具体的实现细节。在文档输入为 HTML 时，简要描述通常被用在描述对象链接身上的提示工具条显示。]

There are several ways to mark a comment block as a detailed description:

[详细描述方法有以下几种：]

- You can use the JavaDoc style, which consist of a C-style comment block starting with two *'s, like this: [你可以采用 JavaDoc 风格（其包含 C 风格）的注释方法，以两个 * 号开始：]
```
/**
 * ... text ...
 */
```
- 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: [或者使用 Qt 风格书写，即在 C 风格的注释开始时加上感叹号：]
```
/*!
 * ... text ...
 */
```
  In both cases the intermediate *'s are optional, so [两种方式中，注释中间的 * 号都是可选的：]
```
/*!
 ... text ...
*/
```
  is also valid.
- 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: ·[第三种替代方案是使用至少有两个 C++ 注释行的块，但需要多加一个斜杠或感叹号，如下：]
```
///
/// ... text ...
///
```
  or
```
//!
//!... text ...
//!
```
  Note that a blank line ends a documentation block in this case. [注意这种情况下需要一个单独的空行来结束注释。]
- 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).
  or
```
/
/// ... text ...
/
```

For the brief description there are also several posibilities: [简要描述也有几种方法：]

- 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. [我们可以在上面的注释块中使用 /brief 命令来表达简要描述。这个命令会自动在该段末尾结束，所以需要加上一个空行隔开：]
  Here is an example:
```
/*! /brief Brief description.
 *         Brief description continued.
 *
 *  Detailed description starts here.
 */
```
- 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: [如果配置文件中 JAVADOC_AUTOBRIEF 标签被设置 YES，那么使用 JavaDoc 风格的注释块将自动被认为是简要描述，直到遇到第一个带有点号+空格（或+新行），如下：]
```
/** Brief description which ends at this dot. Details follow
 *  here.
 */
```
  The option has the same effect for multi-line special C++ comments:[点号+空格对多行的C++注释也有效。]
```
/// Brief description which ends at this dot. Details follow
/// here.
```
- A third option is to use a special C++ style comment which does not span more than one line. Here are two examples: [第三种是使用不超过一行的 C++风格注释，如下：]
```
/// Brief description.
/** Detailed description. */
```
  or
```
//! Brief descripion.

//! 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. [注意：以上后一个例子中空行是必须的，此时 JAVADOC_AUTOBRIEF 应设置为 NO。]

As you can see doxygen is quite flexible. If you have multiple detailed descriptions, like in the following example:

[正如你所看到的，doxygen 使用方法非常灵活。如果你需要多个详细描述（如下）]

//! 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.

[它们会被整合在一起，即使描述位于代码中不同位置。不过这种情况下，整合的顺序取决于 doxygen 处理代码的顺序。]

Here is an example of a documented piece of C++ code using the Qt style: [Qt 风格 C++ 实例：]

//!  A test class.  
/*!
  A more elaborate class description.
*/

class 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.
    */
    Test();

    //! A destructor.    
    /*!
      A more elaborate description of the destructor.
    */
   ~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 Test(), ~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);
};

Click here for the corresponding HTML documentation that is generated by doxygen.[点击此处查看效果]

The one-line comments contain a brief description, whereas the multi-line comment blocks contain a more detailed description.

[单行注释包含了简要描述，而多行描述包含了详细描述。]

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 config 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.

[简要描述被作为类、命名空间或文件的概览，并使用小号斜体输出。默认情况下，简要描述成为详细描述之前的第一个句子，对于Qt风格的注释详细描述和简要描述均是可选的。]

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 automatically treated as a brief description. To enable this behaviour 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:

[默认情况下，JavaDoc 风格文档块与 Qt 风格的以同样的方式被处理，不象 JavaDoc 的规范：第一句注释被认为是简要描述，而是需要设置 JAVADOC_AUTOBRIEF 为 YES 才可以。如果你这样设置，但又想在句子中使用点号（不作为句子的结束），你应当在点号后输入反斜杠并加一个空格，如下： ]

  /** 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:

[下面是如上一样的代码，但使用 JavaDoc 风格，并设置 JAVADOC_AUTOBRIEF 为 YES：]

/**
 *  A test class. A more elaborate class description.
 */

class 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.
       */
      Test();

      /**
       * A destructor.
       * A more elaborate description of the destructor.
       */
     ~Test();
    
      /**
       * a normal member taking two arguments and returning an integer value.
       * @param a an integer argument.
       * @param s a constant character pointer.
       * @see Test()
       * @see ~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);
};

Click here for the corresponding HTML 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.

[同样，如果我们希望 Qt 风格注释块中第一个句子自动为简要描述，我们应该设置 QT_AUTOBRIEF 为 YES。]

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.

[Doxygen 不象其他文档系统，它同时允许我们在成员定义块前放置文档。这种方式可以允许文档置于源文件中，而不只是头文件。这个功能可以保证头文件格式简练，并允许成员的 implementer更直接地访问到文档。综上，最好是将简要描述放置在详细描述之前，而同时详细描述放置在定义之前。]

3. Doxygen入门（3）--代码标记方法

Putting documentation after members

If you want to document the members of a file, struct, union, class, or enum, and you want to put the documentation for these members inside the compound, 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 */

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

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

int var; ///< Brief description after the member

For functions one can use @param 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 direction 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 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 */
};

Click here for the corresponding HTML 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 and enums themselves. Furthermore, the structural commands mentioned in the next section (like /class) are not allowed inside these comment blocks.

Documentation at other places

So far we have assumed that the documentation blocks are 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 "in 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).

Let's repeat that, because it is often overlooked: to document global objects (functions, typedefs, enum, macros, etc), youmust 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);

Click here for the corresponding HTML 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.

4. Doxygen入门（4）--主要标记命令

以下命令的详细解释来自

http://www.stack.nl/%7Edimitri/doxygen/commands.html#cmd？

？=某个命令，如 /image，则 ?=image

/class
/brief 简要描述
/image
/ingroup
/sa
/file
/relates
/note
/ref
/verbatim /endverbatim
/def
/link /endlink
/code /endcode

/image <format> <file> ["caption"] [<sizeindication>=<size>]

/image <格式> <文件名> ["图像悬停字"] [<类别>=<大小>]

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. Currently, the following values are supported: html and latex.

[输出格式，目前两种，html 和 latex。]

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 it. You can also specify an absolute URL instead of a file name, but then doxygen does not copy the image nor check its existance.

[图像路径参数，doxygen 将在 IMAGE_PATH 中寻找。 ]

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 is only useful for $/mbox{/LaTeX}$ output (i.e. format=latex). The sizeindication can be either width or height. The size should be a valid size specifier in (for example 10cm or 6in or a symbolic width like /textwidth).

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

Warning:

The image format for HTML is limited to what your browser supports. For $/mbox{/LaTeX}$

, the image format must be Encapsulated PostScript (eps).

Doxygen does not check if the image is in the correct format. So you have to make sure this is the case!

/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.

[sa = see alse，可以参见很多，用逗号隔开。与 /see 同用。]

See also:

section autolink for information on how to create links to objects.

/file [<name>]

/file [<文件名>]

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.

[表明注释部分属于某个源文件或头文件。如果文件有重名，文件名可以包含路径。如果文件名忽略，比如 /file 后留空，那么包含 /file 的注释将属于它们所在的文件。]

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.

[ 全局函数、变量、类型定义、枚举型等的文档只有当它们所在的文件被标记时才会在输出文档中显示。]

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;

Click here for the corresponding HTML documentation that is generated by doxygen.

Note:

In the above example JAVADOC_AUTOBRIEF has been set to YES in the configuration file.

/class <name> [<header-file>] [<header-name>]

/class <类名称>[<头文件相对地址>][<头文件名称>]

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 [写上头文件地址会显示在文档的 inlude<>中。] . 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 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
 */

Click here for the corresponding HTML documentation that is generated by doxygen.

/verbatim

Starts a block of text that will be verbatim included in both the HTML and the $/mbox{/LaTeX}$

documentation. The block should end with a /endverbatim block. All commands are disabled in a verbatim block.
[将 /verbatim 和 /endverbatim 中的文字一字不差的呈现在 HTML 或 $/mbox{/LaTeX}$