차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

--- develop:doc:doxygen:docblocks [2011/07/19 11:58]
starlits
+++ develop:doc:doxygen:docblocks [2011/07/19 11:59] (현재)
starlits
@@ 줄 257: / 줄 257: @@
 ===== 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 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 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 before (or after) an item is the need to put a structural command inside the documentation block, which leads to some duplication of information.
+  - uctural 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: <code>
-uctural 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: <code>
 /*! \class Test
     \brief A test class.
@@ 줄 266: / 줄 265: @@
 */
 </code>
+  - Here the special command \class is used to indicate that the comment block contains documentation for the class Test. Other structural commands are: <code>
-Here the special command \class is used to indicate that the comment block contains documentation for the class Test. Other structural commands are: <code>
 \struct to document a C-struct.
 \union to document a union.
@@ 줄 280: / 줄 277: @@
 \interface to document an IDL interface.
 </code> See section [[http://www.stack.nl/~dimitri/doxygen/commands.html | 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), you must document the file in which they are defined. In other words, there must at least be a <code>
-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), you must document the file in which they are defined. In other words, there must at least be a <code>
 /*! \file */
 </code> 또는 <code>
  /** @file */
 </code>
+  - Here is an example of a C header named structcmd.h that is documented using structural commands:  <code>
-Here is an example of a C header named structcmd.h that is documented using structural commands:  <code>
 /*! \file structcmd.h
     \brief A Documented file.
@@ 줄 351: / 줄 342: @@
 int read(int,char *,size_t);
 </code> Click [[http://www.stack.nl/~dimitri/doxygen/examples/structcmd/html/structcmd_8h.html | 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.
-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.

adminschool.net wiki

사용자 도구

사이트 도구

차이

문서 도구