В примерах из предыдущей секции блоки документирования всегда располагались перед декларацией или определением файла(видимо имеется в виду элементы файла,прим. пер.), класса, пространства имен, перед или после одного из их элементов. Хотя это часто удобно, иногда может возникнуть необходимость поместить документирование где-то в другом месте. Для документирования файла это даже необходимо, так как нет такого места как «перед файлом».

Doxygen позволяет Вам помещать свои блоки документации фактически где угодно (за исключением тела функции, или в обычном блоке комментария в стиле C).

Платой за то, чтобы не помещать блок документации непосредственно перед (или после) элементом, является необходимость поместить структурную команду в блоке документации, которая приводит к некоторому дублированию информации. Поэтому на практике структурные команды не используют пока в этом нет острой необходимости.

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), 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);

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.