Commenting a region of code in C++ for Doxygen recognition - doxygen

Is there a way to add a comment block that will be understood by Doxygen to a region of code (delineated by #pragma region)?
In other words, I want to put in a comment, that Doxygen will recognize, before a group of functions:
/**********************//**
* \some-doxygen-tag-here ?
**************************/
#pragma region Demo Functions
.....
.....
#pragma endregion

Doxygen module groups can help here. Group can have documentation and you can mark the beginning and the end of a group. Groups are called Modules in output documentation (not sure if this can be easily changed).
/** #defgroup demofuns Demo Functions
* Documentation of the following code block, i. e. group.
* #{
*/
#pragma region Demo Functions
.....
.....
#pragma endregion
/** #} */ // end of demofuns
See http://doxygen.org/manual/grouping.html.

Related

How to apply a warning to several member at once (as all in a group)?

The problem
I have a documentation split into two different groups :
API, intended for regular users, with only safe functions.
Low level API, intended for more confident users.
I added a #warning directive into my Low level API group definition, stating that all member of the group shall be used with care.
I would like this warning to be displayed in the description of every member of the group, so even if users reach member through links and so on, they are warned.
Is there a way to do that without manually adding the #warning to every members of the group, and instead apply per group/per file warning ?
More information
My version of Doxygen is 1.8.17, however I should be able to upgrade it if required.
I can edit all files of the project, as well as the Doxygen configuration file.
Example of wanted behavior
I want to achieve following behavior :
/** #addtogroup low_level_api
#warning This is a warning I want to display in every member of the group
#{
*/
/** #brief some function of my example
#warning This is a warning I want to display in every member of the group
*/
void some_group_member()
/** #brief another function of my example
#warning This is a warning I want to display in every member of the group
*/
void some_group_member()
/**
#}
*/
Without needing to copy-paste the warning in every member of the group, as an hypothetical :
/** #addtogroup low_level_api
#warning_to_all This is a warning I want to display in every member of the group
#{
*/
/** #brief some function of my example
*/
void some_group_member()
/** #brief another function of my example
*/
void some_group_member()
/**
#}
*/
Of course, #warning_to_all directive does not exists, so I need to find an equivalent of this, even if it is a more general and "rough" solution than propagating a warning, as for example displaying the group description in every member description.
There is no real grouping in the sense as OP wants of warnings (as far as I know. A solution might be to use the \snippet{doc} command like:
/** #addtogroup low_level_api
\snippet{doc} this snip
#{
*/
/** #brief some function of my example
\snippet{doc} this snip
#warning This is a warning I want to display in every member of the group
*/
void some_group_member();
/** #brief another function of my example
\snippet{doc} this snip
#warning This is a warning I want to display in every member of the group
*/
void some_group_member1();
/**
#}
*/
/*
[snip]
#warning This is a general warning I want to display in every member of the group
[snip]
*/

In JSDoc, is there a way to define terms in a separate file and link them within function docs?

What I would like is to write something like this:
/**
* Takes a foo and {#link grokelates} it.
*/
function doSomething(foo) {
}
And have "grokelates" be a link to more detail on what "grokelate" means, but because I'm going to have functions dealing with grokelation all over my code base, I'd like to write that definition once and link to it in multiple places.
Is this possible?
To be clear, grokelates is not a function. It's just a word I want to define, but not have to define in-line everywhere I use it. I basically want to write a glossary file and be able to link to definitions from that glossary in my JSDoc.
Ideally this would also be in a way the VS Code picks it up and lets someone navigate to that definition on hover.
Yes there is. When you run jsdoc to generate your documentation, you can pass it any filetype you wish. A standard practice is to create one or more *.jsdoc files which contain doclet comments (those that begin with /**) to describe features you expect to use elsewhere in your code. For instance:
// filename: grokelation.jsdoc
/**
* #module grokelates
*/
/**
* #name Grokelate
* #memberof module:grokelates
* #description
* Here is the description of the grokelation process.
*
* #example
* var g = new Grokelate(opts);
*/
Then, when you wish to reference this new object elsewhere in your documentation, simply use its long name module:grokelates~Grokelate where you can consider the ~ glyph to mean "member of".
In your example above, you'd say {#link module:grokelates~Grokelate}.

Dynamic hyper link reference in Doxygen

Can Doxygen build references such as a link is defined somewhere only once and any reference to it gets the corresponding redirection?
This would allow for \see commands pointing to the right resource without the need of duplicating the URL everywhere in the code, while making it easy to change said link if need be.
Generated docs would look a little bit like this:
mainpage.md
Useful links are defined here
A guide to something
Datasheet of something
source.c File Reference
(...)
See also
A guide to something //points to URL defined in mainfile.md
[EDIT]
Thanks to #albert in the comments, I've managed to do just that using \snippetdoc, however any text after the block-id makes doxygen unable to render the snippet.
Working example:
Knowing that my links are defined in the docs/mainpage.dox file like this:
[url_to_link1]
Link description
[url_to_link1]
[url_to_link2]
Link description
[url_to_link2]
This works:
/**
* \file
* \section links "Useful Links"
* - \snippetdoc docs/mainpage.dox url_to_link1
* - \snippetdoc docs/mainpage.dox url_to_link2
*/
This doesn't:
/**
* \file
* \brief Some function definition
* \see API reference on specific subject (more info: \snippetdoc docs/mainpage.dox url_to_link1)
*/
Doxygen version is 1.8.14
As indicated in the question and comments a solution for this problem lies in the command \snippetdoc, an alternative is to define an ALIAS (in Doxyfile the doxygen configuration file) for the reference and use the defined command / alias on the required places.
As indicated by OP possible solutions by means of \snippetdoc are:
/**
* \file
* \section links "Useful Links"
* - \snippetdoc docs/mainpage.dox url_to_link1
* - \snippetdoc docs/mainpage.dox url_to_link2
*/
The following version does not work as indicated by OP:
/**
* \file
* \brief Some function definition
* \see API reference on specific subject (more info: \snippetdoc docs/mainpage.dox url_to_link1)
*/
The problem is that the definition of \snippetdoc is \snippetdoc <file-name> ( block_id ) where (block_id) means that it reads till the end of the line (see the doxygen documentation) and thus the closing ) is part of the block_id and cannot be resolved.
A possible better implementation could be <block_id> so that block_id is a single word. Problem for this is that this that it might break existing documentation where e.g. spaces or dots are used in the block_id.
There are a number of solutions for this problem:
1) Define the closing ) as part of the block_id (in the not working version):
[url_to_link1)]
Link description)
[url_to_link1)]
2) Place the closing ) on the next line (definition can stay as in the question):
/**
* \file
* \brief Some function definition
* \see API reference on specific subject (more info: \snippetdoc docs/mainpage.dox url_to_link1
* )
*/
3) Define 2 definitions:
[url_to_link1)]
Link description)
[url_to_link1)]
[url_to_link1]
Link description
[url_to_link1]
I general solution 2) is the preferred solution as the solution. All text following the block_id has to be on the next line.

IntelliJ space added after comment starting with /** in scala

In IntelliJ IDEA 2016.3.3 the comment code is formatted like this:
/** ***********************/
/* BACKEND CONFIGURATION */
/** ***********************/
Notice the space after /**
Is it possible to remove that space?
= UPDATE =
To be more precise, I am using these comments solely in-line to (same as I did in java) mark important blocks if algorithm is lengthy.
I just have tested this
/************************
* Test text
* #param jobConfig
*/
class AutoencoderTrainingJob(val jobConfig: Sometype
scaladoc is being displayed by IntelliJ Quick Documentation. The additional asterisks just show up as part of class descirption

doxygen separate interface(.h)/implemetation(.c) documentation

I'm trying to generate a doxygen document where I have two documentation instances for functions. One describes the usage(interface) of the functions that get pulled from the function header in the .h file and the other describes implementation of the function that gets pulled from the .c file. I basically want to describe the same function in two different ways based on where the file that the description came from(.h or .c). I thought this would help the usability of the document since you can easily ignore the implementation details if you only care about how to use the functions. My best attempt was to try to add the .h and the .c files to separate groups like this.
example.h
/**
* #defgroup exampleInterface Example Interface
* #{
*/
/**
* This is the header file so I describe how to use this function
* #param arg
* #returns something
*/
int someFunction(int arg);
/**
* #}
*/
example .c
/**
* #defgroup exampleImpl Example Implementation
* #{
*/
/**
* This is the .c file so I describe how this function is implemented.
*/
int someFunction(int arg)
{
... Some code ...
}
/**
* #}
*/
The result was that the function header descriptions were still combined. Is there anyway to accomplish this in doxygen? Maybe there is another way I should look at this problem.
Thanks.
A possible hack you could try is to use the #internal command for the implementation which would mean you would run doxygen twice: once without the internal (for the external definitions) and the other with the inernal which would combine them.