Woody,
Doxygen does not write documentation for you; it formats and cross-references
documentation you have written.
Doxygen generating a cross-reference to "control::V2" (which is a common
convention to referring to a struct type member[1]) for the expression
table_pointer->V2 is exactly what
> Perhaps it needs a set of options use only C syntax, and use
descriptions from within the function body, and use the actual function
header rather than the prototype.
I don't know if it will take care of the specific issues that you've been
describing, but there is (in Doxygen 1.8.10, and I
what causes this?
there is a
structure control
{
int V1;
int V2;
};
a declaration
struct control control_arrays;
within a function, a declaration of a pointer to the structure
struct control * table_pointer;
table_pointer=control_arrays
i.e. a pointer is set to point to a con
At 03:38 PM 9/4/2015 +, you wrote:
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_acddece4335344f69994c1160549d3aePineMailboxLANGROUPloca_"
From the peanut gallery: Seems to me a reasonable thing to have as an
option in the doxygen configuration, the option for
>From the peanut gallery: Seems to me a reasonable thing to have as an option
>in the doxygen configuration, the option for parameter names to be taken from
>the definition rather than the prototype. With that said, the \param special
>command's first argument is the parameter name. I haven't
At 09:00 AM 9/4/2015 +0100, Frank Peelo wrote:
If you're really going to have different parameter names, the ones in the
header should be the ones documented. The documentation is for people who
are going to use the function;
Precisely, that is why it should be the FUNCTION ACTUAL HEADER
the
If you're really going to have different parameter names, the ones in
the header should be the ones documented. The documentation is for
people who are going to use the function; the people working on the
function body can read the code. People using the function can see the
.h file, which has