Adjusted the text a bit

1 files changed, 94 insertions, 95 deletions

diff --git a/doc/docblocks.doc b/doc/docblocks.doc
index 3137663..92bf3df 100644
--- a/doc/docblocks.doc
+++ b/doc/docblocks.doc
@@ -1,12 +1,12 @@
 /******************************************************************************
  *
- * 
+ *
  *
  * Copyright (C) 1997-2015 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 
+ * 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.
  *
@@ -19,35 +19,35 @@
 
 This chapter covers two topics:
 1. How to put comments in your code such that doxygen incorporates them in
-   the documentation it generates. 
+   the documentation it generates.
    This is further detailed in the \ref specialblock "next section".
 2. Ways to structure the contents of a comment block such that the output
    looks good, as explained in section \ref docstructure.
 
-\section specialblock Special comment blocks 
+\section specialblock Special comment blocks
 
-A special comment block is a C or C++ style comment block with some 
+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 \ref cppblock "next" section
 presents the various styles supported by doxygen.
 
-For Python, VHDL, and Fortran code there are different commenting 
+For Python, VHDL, and Fortran code there are different commenting
 conventions, which can be found in sections \ref pythonblocks, \ref vhdlblocks, and
 \ref fortranblocks respectively.
 
 \subsection cppblock 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, 
+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 
+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, 
+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
@@ -64,7 +64,7 @@ block starting with two *'s, like this:
  */
 \endverbatim
 
-<li> or you can use the Qt style and add an exclamation mark (!) 
+<li> 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:
 
 \verbatim
@@ -83,8 +83,8 @@ In both cases the intermediate *'s are optional, so
 
 is also valid.
 
-<li> A third alternative is to use a block of <i>at least two</i> C++ comment 
-lines, where each line starts with an additional slash or an 
+<li> A third alternative is to use a block of <i>at least two</i> C++ comment
+lines, where each line starts with an additional slash or an
 exclamation mark. Here are examples of the two cases:
 
 \verbatim
@@ -146,8 +146,8 @@ as long as JAVADOC_BANNER = YES is used.
 
 For the brief description there are also several possibilities:
 <ol>
-<li>One could use the \ref cmdbrief "\\brief" command with one of the 
-above comment blocks. This command ends at the end of a paragraph, 
+<li>One could use the \ref cmdbrief "\\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:
@@ -160,8 +160,8 @@ Here is an example:
  */
 \endverbatim
 
-<li>If \ref cfg_javadoc_autobrief "JAVADOC_AUTOBRIEF" is set to \c YES 
-    in the configuration file, 
+<li>If \ref cfg_javadoc_autobrief "JAVADOC_AUTOBRIEF" is set to \c 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:
@@ -177,7 +177,7 @@ The option has the same effect for multi-line special C++ comments:
 /// here.
 \endverbatim
 
-<li>A third option is to use a special C++ style comment which does not 
+<li>A third option is to use a special C++ style comment which does not
     span more than one line. Here are two examples:
 \verbatim
 /// Brief description.
@@ -189,11 +189,11 @@ or
 \verbatim
 //! Brief description.
 
-//! Detailed description 
+//! Detailed description
 //! starts here.
 \endverbatim
 
-Note the blank line in the last example, which is required to separate the 
+Note the blank line in the last example, which is required to separate the
 brief description from the block containing the detailed description. The
 \ref cfg_javadoc_autobrief "JAVADOC_AUTOBRIEF" should also be set to \c NO
 for this case.
@@ -216,40 +216,40 @@ 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 \e 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 
+the documentation of members (including global functions) in front of
+the \e 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.
 
-\subsubsection memberdoc Putting documentation after members 
+\subsubsection memberdoc 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 
+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 
+in the comment block. Note that this also works for the parameters
 of a function.
 
 Here are some examples:
 \verbatim
 int var; /*!< Detailed description after the member */
 \endverbatim
-This block can be used to put a Qt style detailed 
+This block can be used to put a Qt style detailed
 documentation block \e after a member. Other ways to do the
 same are:
 \verbatim
 int var; /**< Detailed description after the member */
 \endverbatim
-or 
+or
 \verbatim
 int var; //!< Detailed description after the member
-         //!< 
+         //!<
 \endverbatim
-or 
+or
 \verbatim
 int var; ///< Detailed description after the member
-         ///< 
+         ///<
 \endverbatim
 
 Most often one only wants to put a brief description after a member.
@@ -263,16 +263,16 @@ int var; ///< Brief description after the member
 \endverbatim
 
 For functions one can use the \ref cmdparam "\@param" command to document the parameters
-and then use <code>[in]</code>, <code>[out]</code>, <code>[in,out]</code> 
-to document the direction. For inline documentation this is also possible 
+and then use <code>[in]</code>, <code>[out]</code>, <code>[in,out]</code>
+to document the direction. For inline documentation this is also possible
 by starting with the direction attribute, e.g.
 \verbatim
 void foo(int v /**< [in] docs for input parameter v. */);
 \endverbatim
 
-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 
+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:
@@ -288,15 +288,14 @@ Here is an example of the use of these comment blocks:
 
 \warning These blocks can only be used to document \e members and \e parameters.
          They cannot be used to document files, classes, unions, structs,
-         groups, namespaces, defines and enums themselves. Furthermore, the structural 
-         commands mentioned in the next section 
-         (like <code>\\class</code>) are not allowed 
+         groups, namespaces, macros, and enums themselves. Furthermore, the structural
+         commands mentioned in the next section
+         (like <code>\\class</code>) are not allowed
          inside these comment blocks.
 
-\warning Don't use this construct with a define as in that cases
-         (when \ref cfg_macro_expansion "MACRO_EXPANSION" is set to `YES`)
-         at places where the define is used the defines is replaced including the comment
-         and this comment is seen as documentation for the last documentable item seen.
+\warning Be careful using this construct as part of a macro definition, because when \ref cfg_macro_expansion "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!
 
 \subsubsection docexamples Examples
 
@@ -311,15 +310,15 @@ Here is an example of a documented piece of C++ code using the Qt style:
  for the corresponding \mbox{\LaTeX} documentation that is generated by doxygen.
  \endlatexonly
 
-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 
-\ref cfg_brief_member_desc "BRIEF_MEMBER_DESC" to \c 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 \ref cfg_repeat_brief "REPEAT_BRIEF" 
-tag to \c NO). Both the brief and the detailed descriptions are optional 
-for the Qt style. 
+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
+\ref cfg_brief_member_desc "BRIEF_MEMBER_DESC" to \c 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 \ref cfg_repeat_brief "REPEAT_BRIEF"
+tag to \c 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
@@ -333,7 +332,7 @@ Here is an example:
   /** Brief description (e.g.\ using only a few words). Details follow. */
 \endverbatim
 
-Here is the same piece of code as shown above, this time documented using the 
+Here is the same piece of code as shown above, this time documented using the
 Javadoc style and \ref cfg_javadoc_autobrief "JAVADOC_AUTOBRIEF" set to YES:
 \include jdstyle.cpp
  \htmlonly
@@ -351,25 +350,25 @@ block to automatically be treated as a brief description, one may set
 
 \subsubsection structuralcommands Documentation at other places
 
-In the examples in the previous section the comment blocks were always located *in 
+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 "in front of a file". 
+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). 
+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  
+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 \e avoid the use of
 structural commands \e unless other requirements force you to do so.
 
-Structural commands (like \ref cmd_intro "all other commands") start with a backslash 
-(<tt>\\</tt>), or an at-sign (<tt>\@</tt>) if you prefer Javadoc style, 
+Structural commands (like \ref cmd_intro "all other commands") start with a backslash
+(<tt>\\</tt>), or an at-sign (<tt>\@</tt>) if you prefer Javadoc style,
 followed by a command name and one or more parameters.
 For instance, if you want to document the class \c Test in the example
 above, you could have also put the following documentation block somewhere
@@ -398,22 +397,22 @@ Other structural commands are:
 <li>\c \\package to document a Java package.
 <li>\c \\interface to document an IDL interface.
 </ul>
-See section \ref commands for detailed information about these and many other 
-commands. 
+See section \ref 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 
+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
-<em>must</em> document the file in which they are defined. In other words, 
+<em>must</em> document the file in which they are defined. In other words,
 there <em>must</em> at least be a \verbatim /*! \file */ \endverbatim
 or a \verbatim /** @file */ \endverbatim line in this file.
 
-Here is an example of a C header named \c structcmd.h that is documented 
+Here is an example of a C header named \c structcmd.h that is documented
 using structural commands:
 \include structcmd.h
  \htmlonly
@@ -426,8 +425,8 @@ using structural commands:
  \endlatexonly
 
  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 
+ 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
@@ -437,7 +436,7 @@ using structural commands:
 
  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 \ref cfg_extension_mapping "EXTENSION_MAPPING" 
+ `md` by means of the \ref cfg_extension_mapping "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,
@@ -456,7 +455,7 @@ the script can be found in the path set via \ref cfg_example_path "EXAMPLE_PATH"
 
 \subsection pythonblocks Comment blocks in Python
 
-For Python there is a standard way of documenting the code using 
+For Python there is a standard way of documenting the code using
 so called documentation strings (<tt>"""</tt>). Such strings are stored in \c __doc__
 and can be retrieved at runtime. Doxygen will extract such comments
 and assume they have to be represented in a preformatted way.
@@ -471,17 +470,17 @@ and assume they have to be represented in a preformatted way.
  for the corresponding \mbox{\LaTeX} documentation that is generated by doxygen.
  \endlatexonly
 
-\note When using <tt>\"\"\"</tt> none of doxygen's \ref cmd_intro "special commands" 
+\note When using <tt>\"\"\"</tt> none of doxygen's \ref cmd_intro "special commands"
 are supported and the text is shown as verbatim text see \ref cmdverbatim "\\verbatim".
 To have the doxygen's \ref cmd_intro "special commands" and have the text as regular
-documentation instead of <tt>\"\"\"</tt> use <tt>\"\"\"!</tt> or set 
+documentation instead of <tt>\"\"\"</tt> use <tt>\"\"\"!</tt> or set
 \ref cfg_python_docstring "PYTHON_DOCSTRING" to \c NO in the configuration file.
 \note Instead of <tt>\"\"\"</tt> one can also use <tt>'''</tt>.
 
-There is also another way to document Python code using comments that 
-start with "##". 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. 
+There is also another way to document Python code using comments that
+start with "##". 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:
 
@@ -495,9 +494,9 @@ Here is the same example again but now using doxygen style comments:
  for the corresponding \mbox{\LaTeX} documentation that is generated by doxygen.
  \endlatexonly
 
-Since python looks more like Java than like C or C++, you should set 
+Since python looks more like Java than like C or C++, you should set
 \ref cfg_optimize_output_java "OPTIMIZE_OUTPUT_JAVA" to \c YES in the
-configuration file. 
+configuration file.
 
 
 \subsection vhdlblocks Comment blocks in VHDL
@@ -546,12 +545,12 @@ By setting `EXTENSION_MAPPING =  f=FortranFixed f90=FortranFree` files with
 extension \c f are interpreted as fixed format Fortran code and files with
 extension \c f90 are interpreted as free format Fortran code.
 
-For Fortran "!>" or "!<" starts a comment and "!!" or "!>" can be used to 
+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:
 \code{.f}
-  !> Build the restriction matrix for the aggregation 
+  !> Build the restriction matrix for the aggregation
   !! method.
   !! @param aggr information about the aggregates
   !! @todo Handle special case
@@ -586,21 +585,21 @@ 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 
+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 
-<a href="https://daringfireball.net/projects/markdown/syntax">Markdown</a> 
+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
+<a href="https://daringfireball.net/projects/markdown/syntax">Markdown</a>
 syntax, including parts of the
 <a href="https://michelf.ca/projects/php-markdown/extra/">Markdown Extra</a>
-extension. 
+extension.
 
-Markdown is designed to be very easy to read and write. 
+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 
+page for your project. Doxygen also supports reading of markdown files
 directly. For more details see chapter \ref markdown.
 
 For programming language specific formatting doxygen has two
@@ -612,7 +611,7 @@ forms of additional markup on top of Markdown formatting.
    as specified in the <a href="http://standards.iso.org/ittf/PubliclyAvailableStandards/c042926_ISO_IEC_23270_2006(E).zip">C# standard</a>.
    See \ref xmlcmds for the XML commands supported by doxygen.
 
-If this is still not enough doxygen also supports a \ref htmlcmds "subset" of 
+If this is still not enough doxygen also supports a \ref htmlcmds "subset" of
 the <a href="https://en.wikipedia.org/wiki/HTML">HTML</a> markup language.
 
 \htmlonly