Doxygen : handling unused function parameters with "UNUSED" macro - doxygen

Short version
To prevent the compiler from raising a warning about unused variables I define the macro UNUSED as:
UNUSED(x)=x __attribute__((__unused__))
This macro is then employed in some functions' prototypes, for instance :
void ext(int foo, int UNUSED( bar ) )
However, doxygen is unhappy about that and returns some warnings:
/tmp/sandbox/main.cpp:13: warning: argument 'bar' of command #param is not found in the argument list of Dummy::ext(int foo, intUNUSEDbar)
/tmp/sandbox/main.cpp:13: warning: The following parameters of Dummy::ext(int foo, intUNUSEDbar) are not documented:
parameter 'UNUSED'
How should I tell doxygen to ignore the UNUSED macro ?
Long version
I have a code that looks like the following :
#include <iostream>
class Dummy
//! Dummy class
{
public :
//!Dummy function
/**
* \param foo First variable
* \param bar Second variable
*/
void ext(int foo, int UNUSED( bar ) )
{
std::cout << "foo = " << foo << std::endl;
}
};
//!Main function
int main(void)
{
Dummy MyDummy;
MyDummy.ext(1, 2);
return 0;
}
I compile it by invoking :
g++ -D 'UNUSED(x)=x __attribute__((__unused__))' main.cpp
To generate the default doxygen configuration file named Doxyfile I enter :
doxygen -g
Eventually, to generate the documentation I enter :
doxygen Doxyfile
The latter command outputs the following warning :
/tmp/sandbox/main.cpp:13: warning: argument 'bar' of command #param is not found in the argument list of Dummy::ext(int foo, intUNUSEDbar)
/tmp/sandbox/main.cpp:13: warning: The following parameters of Dummy::ext(int foo, intUNUSEDbar) are not documented:
parameter 'UNUSED'

Following instructions from the doxygen documentation, modify the Doxyfile so that it has the following parameters :
#Doxygen will run its own preprocessor before parsing the file
ENABLE_PREPROCESSING = YES
#The Doxygen preprocessor will not only define the macros (default
#behaviour) but also expand them
MACRO_EXPANSION = YES
#The Doxygen preprocessor will only expand the macros that are listed in
#the PREDEFINED setting. Any other macro will merely be defined, and not
#expanded.
EXPAND_ONLY_PREDEF = YES
#The Doxygen preprocessor will replace any occurrence of the UNUSED
#macro by its argument
PREDEFINED = UNUSED(x)=x
After those changes, invoking doxygen Doxyfile no longer raises warnings.

Related

How to force g++ to create C symbol name

I have a function called init in a cpp file, but when I compile it, g++ creates in the object file a symbol named _Z4initv, so when I link after with ld with the option -e init, obviously ld doesn't recognize the symbol init. Is there a way to create symbols name in C style with g++ ?
If you have a definition like e.g.
void init() { ... /* some code */ ... }
Then to inhibit name mangling you need to declare it as extern "C":
extern "C" void init() { ... /* some code */ ... }
If you have a declaration in a header file that you want to include in a C source file you need to check if you're including the header file in a C or C++ source file, using the __cplusplus macro:
#ifdef __cplusplus
extern "C"
#endif
void init(void);
Note that the function in the header file has to be declared with void in the argument list, if it doesn't take any arguments. That's because the declaration void init() means something else in C.

Doxygen: Force undeclared functions to be documented

Our C++ program has a built-in script interface and is able to run scripts in it. The scripts have access to convenience functions provided by the C++ program.
Now we would like Doxygen to create the documentation of the functions the script has access to. Such a function declaration looks like this:
void ScriptEngine::load_script(const QString &path) {
//...
/*! \fn sleep_ms(const unsigned int timeout_ms)
\brief sleeps for timeout_ms milliseconds.
\param timeout_ms
*/
(*lua)["sleep_ms"] = [](const unsigned int timeout_ms) {
//sleep(timeout_ms)
};
//more convenience functions..
//...
}
Obviously Doxygen won't include a
sleep_ms(const unsigned int timeout_ms)
into the documentation. Is there a way to to tell Doxygen to do so?
Do this:
Add the following line to your Doxyfile:
PREDEFINED = _DOXYGEN_
Make sure the ENABLE_PREPROCESSING tag in the Doxyfile is set to YES.
Put your declarations and documentation for the undeclared functions inside an #ifdef _DOXYGEN_ section.
#ifdef _DOXYGEN_
/*! \fn sleep_ms(const unsigned int timeout_ms)
\brief sleeps for timeout_ms milliseconds.
\param timeout_ms
*/
void sleep_ms(const unsigned int timeout_ms);
#endif
Don't put the above code inside a method or function such as ScriptEngine::load_script(), as you previously tried. And don't put it inside a namespace or class, unless in fact the function being declared is a member of that namespace or class.
With this method, your declarations will not create linker errors during a normal build, but will be seen by Doxygen.
See Also
http://www.doxygen.nl/manual/config.html#cfg_predefined

Is it possible for Doxygen to exclude undocumented functions from generated XML?

I want to generate documentation only for code that has Doxygen comments. I have created a Doxyfile via Doxygen version 1.8.9.1 and configured it to output only XML and to hide all undocumented code:
GENERATE_HTML = NO
GENERATE_LATEX = NO
GENERATE_XML = YES
HIDE_UNDOC_MEMBERS = YES
HIDE_UNDOC_CLASSES = YES
After that I created a simple C header test.h with one documented and one non-documented function declaration:
void foo(int a);
/**
* "bar" function description
* #param b sample param
*/
void bar(int b);
By executing doxygen I expected only documentation for bar to be included in the resulting XML. Unfortunately, documentation for both functions is generated. Is it possible to generate documentation only for code that has Doxygen comments? Or will Doxygen always include everything in the XML output regardless of settings?
Before reading any further make sure EXTRACT_ALL is set to NO.
I'm not a fan of the following solution but it does work. Use doxygen's preprocessor
#ifdef PROJECT_NO_DOC
void foo(int a);
#endif /* PROJECT_NO_DOC */
/**
* * "bar" function description
* * #param b sample param
* */
void bar(int b);
Note, in their docs you have to set a PREDEFINED macro but at least in my version of doxygen this was not required. Their docs specify to do it this way set a predefined macro in the config to do it for you
#ifndef DOXYGEN_SHOULD_SKIP_THIS
/* code that must be skipped by Doxygen */
#endif /* DOXYGEN_SHOULD_SKIP_THIS */
around the blocks that should be hidden and put:
PREDEFINED = DOXYGEN_SHOULD_SKIP_THIS
in the config file then all blocks should be skipped by doxygen as long as
ENABLE_PREPROCESSING = YES
There are other methods but they come with additional constraints ie to make sure no static method appear in your public docs you can set EXTRACT_STATIC to NO.
You can use \cond to hide parts of the source code from Doxygen. This avoids the need to use the preprocessor as in Harry's answer.
For example, here foo will not be seen by Doxygen, and hence not documented:
/** \cond */
void foo(int a);
/** \endcond */
/**
* "bar" function description
* #param b sample param
*/
void bar(int b);
Furthermore, it is possible to add section labels to \cond, and control which sections are included by listing them in the ENABLED_SECTIONS configuration option.
For example:
/// \cond CLASS_A
/// This function foos `a`.
void foo(int a);
/// \endcond
/// \cond CLASS_B
/// This function bars `b`.
void bar(int b);
/// \endcond
By setting ENABLED_SECTIONS = CLASS_A CLASS_B, both functions will show up in the documentation. Leaving one of the labels out will hide the corresponding function.

PostgreSQL + lexical definition of GROUP_P

Where can I find lexical definitions of all PostgreSQL keywords / tokens, like GROUP_P?
GROUP_P is not a keyword, it's a symbol in the context of the C compiler and it doesn't have lexical significance outside of the C source code.
In this declaration from parser/kwlist.h:
PG_KEYWORD("group", GROUP_P, RESERVED_KEYWORD)
it is the first argument "group" that is the keyword, the 2nd argument GROUP_P being typically an enum field or a #define (it's up to the includer).
The header file src/include/parser/keywords.h provides a struct type ScanKeyword that can be directly mapped to the PG_KEYWORD macro, field by field:
typedef struct ScanKeyword
{
const char *name; /* in lower case */
int16 value; /* grammar's token code */
int16 category; /* see codes above */
} ScanKeyword;
For a concrete example of use, see how ECPG does it in src/interfaces/ecpg/preproc/keywords.c

Eclipse undefined reference

I'm using Eclipse and MinGW. I've got undefined reference to error to all that I write in h files, that I do include in cpp-file where main located. I create an empty project, and the same thing again (
main.cpp
#include <iostream>
#include "Stack.h"
using namespace std;
int main(){
Stack<int> stack(10);
cout << "!!!Hello World!!!" << endl; // prints !!!Hello World!!!
return 0;
}
stack.h
#ifndef STACK_H_
#define STACK_H_
template <class T>
class Stack{
private:
struct StackEl;
StackEl *top;
public:
Stack();
Stack(T el);
~Stack();
void Push(const T& el);
T Pop();
};
#endif /* STACK_H_ */
and stack.cpp inplements everything from stack.h
If I include not h-file, but cpp - all works. Help please!
I've got following errors
D:/Workspacee/Stack2/Debug/../src/Stack2.cpp:16: undefined reference to `Stack<int>::Stack(int)'
D:/Workspacee/Stack2/Debug/../src/Stack2.cpp:18: undefined reference to `Stack<int>::~Stack()'
D:/Workspacee/Stack2/Debug/../src/Stack2.cpp:18: undefined reference to `Stack<int>::~Stack()'
This is a linker error. I'm no Eclipse expert, but you have to tell it somehow to add Stack.o to the linking command.
If you include Stack.cpp instead of Stack.h, the implementations from the cpp-file get included into main.cpp by the preprocessor before compilation, so the linking stage has no unresolved references to outside functions.
My bad, that is becouse templates! When you use template, all code, including realization of functions, must be in header-file, or you have to write prototypes for every type you are going to use you template-functions with. I've forgot about that working with templates is not the same as with usual function :(