I wasn't able to show documentation for values of enum classes without setting EXTRACT_ALL. The comments for preserve, truncate and append aren't there. The enum itself is documented. If I enable EXTRACT_ALL I get a list.
My code is:
namespace grimoire
{
...
/// #brief Behaviour of function open_for_write for already existing files.
/// #see open_for_write()
enum class OpenMode
{
preserve = std::ofstream::out, /// Already existing file aren't opened.
truncate = std::ofstream::trunc, /// Discard existing contents.
append = std::ofstream::app /// Append to existing contents.
};
...
}
I'm using CMake to run Doxygen with:
#set(DOXYGEN_EXTRACT_ALL YES)
doxygen_add_docs(
docs
"${CMAKE_CURRENT_SOURCE_DIR}/include/grimoire"
"${CMAKE_CURRENT_SOURCE_DIR}/src")
Edit:
It doesn't even work with a classical enum and without explicit values. It looks like it has to do with my settings.
Solved:
I had to add a comment to the enclosing namespace. Doxygen extracted the enum itself and other stuff like functions and classes inside that namespace but not the enum entries.
Doxygen does not always pickup an enum, this can be overcome by means of using the \file command.
Furthermore you document the enum values after its definition, this means you should not use /// but ///<
So the limited example would looks like:
/// \file
/// #brief Behavior of function open_for_write for already existing files.
/// #see open_for_write()
enum class OpenMode
{
preserve = std::ofstream::out, ///< Already existing file aren't opened.
truncate = std::ofstream::trunc, ///< Discard existing contents.
append = std::ofstream::app ///< Append to existing contents.
};
Edit:
Based on the answer from OP, the given solution was not complete as the original problem was embedded in an namespace. To be able to show the enum in that case it is not sufficient to add the \file but it is also necessary the document the namespace. So a more complete example:
/// \file
/// The namespace documentation
namespace NS
{
/// #brief Behavior of function open_for_write for already existing files.
/// #see open_for_write()
enum class OpenMode
{
preserve = std::ofstream::out, ///< Already existing file aren't opened.
truncate = std::ofstream::trunc, ///< Discard existing contents.
append = std::ofstream::app ///< Append to existing contents.
};
};
Related
Running doxygen for
namespace BV
{
namespace Data
{
typedef struct Station {
uint offsetId; //! The ID of a station is generated by adding an offset to a base (example: 1000)
uint id; //! The ID of the station (see {#link Station.offsetId} for more details)
QString name; //! Name of the station
QStringList lineSwitches; //! A list of available lines the passanger can switch to from the station
} Station;
...
}
}
returns warning
/home/USER/Projects/HelloWorld/src/csvparser.h:16: warning: unable to resolve link to `Station.offsetId' for \link command
Initially I only had offsetId instead of Station.offsetId but after looking online I saw a bunch of examples (including here on SO) that were describing this to be the way. Besides I also want to reference this member in other parts of my header.
Not only do I get the warning from above but I just took a look at the generated HTML documentation for my structure and for my surprise it wasn't even there:
Public Attributes
uint id
The ID of a station is generated by adding an offset to a base (example: 1000)
QString name
The ID of the station (see **Station.offsetId** for more details)
QStringList lineSwitches
Name of the station.
The Station.offsetId is just a broken link.
The documentation as stated in the question uses //! as comment strings, this is intended for usage before the member. When having the documentation after the member one should use //!<. See also "Putting documentation after members" in the doxygen manual.
As a second part it is not necessary to use: {#link Station.offsetId} (actually \link should also have a \endlink. Better is to use \ref or # e.g. \ref Station.offsetId or #offsetId or \ref offsetId or in (this case) just Station.offsetId.
I would like to generate a documentation of certain parameters that the Save-Method of various classes in my program generate. For that purpose, I would like to write a comment at the top of my save method, and these comments should go to a html and PDF file.
I would like to use doxygen to parse the source- and header files of my C++ project, however by default, doxygen generates a documentation for all the members and classes in my project, which is not what I actually want.
Is it possible to customize doxygen to generate documentation for only one single method which always has the same signature and Name (int Save();), and nothing else? How can that be achieved?
Have you looked at ENABLED_SECTIONS and the cond command? Here is a snippet of the example:
/// #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.
If this does not help, please clarify your question.
Doxygen is not adding the documentation of any of my member functions in this class:
#ifndef SET_H_
#define SET_H_
/** #file */
/**
* A mathematical set
*/
class Set
{
virtual ~Set();
/**
* The countability of this set
* #returns Whether this set is a countable one or not.
*/
virtual bool isCountable();
...
}
#endif /* SET_H_ */
It produces the class documentation just fine, but not the function documentation even if I set EXTRACT_ALL to YES. Do you know why this is the case?
The function is private unless declared otherwise as public or protected.
By default, doxygen excludes private functions, even when setting EXTRACT_ALL is true. You can include them by adding to the Doxyfile EXTRACT_PRIVATE = YES.
Quoting from Doxygen's FAQ:
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
config file.
Are the members private? If so, you must set
EXTRACT_PRIVATE to YES to make them appear in the documentation.
Consider I have 2 header files.
// HEADER 1
/**
* Doc for Foo here?
*/
namespace Foo {
class This {...};
}
&&
// HEADER 2
/**
* Doc for Foo here?
*/
namespace Foo {
class That {...};
}
How should I handle this when documenting with Doxygen?
Maybe neither.
For example, imagine you have "<root>/utility/header1.hpp" which has its contents in namespace utility and "<root>/utility/header2.hpp" which does also.
You could add a file: "<root>/utility.hpp" which documents the utility namespace. You could put this at the top #error Documentation only. to make sure it's not accidentally included.
But I would recommend at least making some out-of-the-way file to keep it in a sane place (and not mixed in randomly with some class.)
I have placed documentation for namespaces that span multiple files into another file. My Doxygen builds use a separate file for the #mainpage tag. This forms the root of the built Doxygen, and is also a central location for such namespaces.
So I'll have project_name_mainpage.h, and in that file:
/**
#mainpage title
...whatever you want to tell the user about your application...
*/
/**
* #namespace your_namespace
* #brief An awesome description
* #details More sweet details
*/
Keeps it all in one place, and is relatively easy to find if you need to update it.
Find the best place for the documentation, whether it is in one of those files or another entirely. Use a comment block with Doxygen's namespace tag:
/**
* #namespace Foo
* Documentation for Foo here. More docs for Foo here,
* and down here.
*/
Docs here: http://www.doxygen.nl/manual/commands.html#cmdnamespace
I'm having issues with Doxygen recognizing namespaces and modules. I believe the issue surrounds whether to place the \addtogroup within the namespace or outside the namespace.
Example 1, outside the namespace:
/*!
* \addtogroup Records
* #{
*/
//! Generic record interfaces and implementations
namespace Records
{
//! Describes the record interface
class Interface;
} // End namespace Records
/*! #} End of Doxygen Groups*/
Example 2 - within namespace
//! Generic record interfaces and implementations
namespace Records
{
/*!
* \addtogroup Records
* #{
*/
//! Describes the record interface
class Interface;
/*! #} End of Doxygen Groups*/
} // End namespace Records
I would like the namespace Records to appear under the Doxygen Namespaces tab and indirectly under the Modules tab. Clicking on the item in the Namespaces page should produce a page containing Records::Interface. Clicking on the item in the Modules tab should also produce a page containing Records::Interface.
In my Doxygen documentation, I have items missing from Namespaces tab that are in Modules and vice-versa, due to my inconsistency resulting from this dilemma.
So which is the proper method, Example 1 or Example 2?
{The Doxygen manual is not clear on this topic.}
Doxygen: \addtogroup
Doxygen: documenting namespaces
I have performed an experiment using Doxygen and the two examples and here are the results.
The class names in the examples have been renamed to avoid confusion with Doxygen.
Example 1, Outside Namespace
/*!
* \addtogroup Records
* #{
*/
//! Generic record interfaces and implementations
namespace Records
{
//! Describes the record interface
class Interface;
} // End namespace Records
/*! #} End of Doxygen Groups*/
Doxygen Results:
Click on Modules button (in the main bar).
Click on "Records" module in the window.
Example 2: Within Namespace (class renamed to Fields)
//! Generic record interfaces and implementations
namespace Fields
{
/*!
* \addtogroup Fields
* #{
*/
//! Describes the record interface
class Interface;
/*! #} End of Doxygen Groups*/
} // End namespace Fields
Doxygen Results:
Click on Modules button (in the main bar).
Click on "Records" module in the window.
Summary
The location of Doxygen \addtogroup command has different results depending on whether it is located within a namespace definition or outside. When declared outside of a namespace, the Doxygen Modules tab will show the namespace, as shown in Example 1 above. When the \addtogroup command is placed inside a namespace, the Doxygen Modules tab will not display the namespaces as shown in Example 2 above. If you want your namespace to be listed in the Doxygen Modules tab, locate the \addtogroup command outside of the namespace.
As an alternative, you could also use \ingroupRecords in the namespace documentation:
/**
* \defgroup Records Title for records module
* #brief Short doc of Records
*
* Long doc of Records.
*/
/**
* #brief Generic record interfaces and implementations
*
* \ingroup Records
*/
namespace Records {
/// Describes the record interface
class Interface;
} /* namespace Records */