How to disable "warning: Found unknown command" in doxygen - doxygen

I'd like to avoid getting this annoying:
Generating docs for compound bla_param...
/home/mathieu/Projects/bla_parser.h:57: warning: Found unknown command `\0'
/home/mathieu/Projects/bla_parser.h:57: warning: Found unknown command `\0'
The only option I can think of is a double escaping, and have:
/** Query parameters */
typedef struct bla_param{
char *cclose; /**< list of params, separated by '\\0' */
But this make my code difficult to read, and add extra work to developers when documenting the API...
Any other solution I did not think of ?

Updating to the latest version of Doxygen may address this issue. I was able to reproduce this warning with Doxygen 1.6.2, but it didn't occur in later versions (I tested 1.7.6.1, 1.8.0 and 1.8.2).

Related

Doxygen doesn't document a class if \code is used

This is either a bug in Doxygen or I am missing something. It is very easy to reproduce as follows:
I have the following class in a foo.h file:
class Foo {
public:
/**
* This is a comment with \code value.
*/
int bar(int value);
};
If I use Doxygen (version 1.8.17) with the default configuration (generated by the doxygen -g command) then class Foo doesn't appear in the produced documentation. If I simply remove the \code symbol in the comment of bar then the class appears. If I put it back, it disappears again and so on.
This looks like a bug. Am I missing something ?
P.S.: I use MacOS 10.15.4 if it makes any difference.
The usage of the command \code is incorrect the closing \endcode is missing.
There are also warnings:
.../aa.h:10: warning: Reached end of file while still inside a (nested) comment. Nesting level 1 (probable line reference: 4)
...
.../aa.h:10: warning: File ended in the middle of a comment block! Perhaps a missing \endcode?
When correcting this you will get the message:
...aa.h:1: warning: Compound Foo is not documented.
but this is clear as the class itself is not documented.
Note it is a bit strange to have \code in a brief description, maybe you should also look at commands like \a, \arg and \param.

Eclipse C++ std::vector methods invalid parameters errors

I am working on an Android application that uses OpenCV 2.4.9 and NDKr9 as dependecies. I also use Eclipse 4.4 Luna as the IDE, with CDT plugin 8.4 installed.
Whenever I'm trying to use the methods std::vector.at(int), or the "[]" method, i get weird errors. For instance, consider the code:
#include <vector>
.........................
struct CustomStruct {
int level;
Point firstPoint, secondPoint, middlePoint;
};
.........................
int maxElemNr = 10;
std::vector<CustomStruct > customStructVector(maxElemNr);
.........................
for(int i=0;i<customStructVector.size();i++){
if(customStructVector.at(i).level == 0){
}
}
At customStructVector.at(i) Eclipse tells me the following:
Invalid arguments ' Candidates are: ResultWithEvidence & at(?) const
ResultWithEvidence & at(?)'
If I want to use the "[]" operator, instead of the "at(index)" method, i get the following:
resultWithEvidenceVector[i].level tells me that the field level is not found.
I am by no means an expert C/C++ coder, and I am rather new at working with the NDK. Coming from a Java background, I was expecting to get an object of type CustomStruct when calling either customStructVector.at(i) or customStructVector[i], such that I could then simply access the field level on my object, to read its value.
Also, declaring my vector as
int maxElemNr = 10;
std::vector<CustomStruct> customStructVector;
customStructVector.reserve(maxElemNr);
I get:
Invalid arguments ' Candidates are: void reserve(?) '
I have searched for answers, and came with the theory that eclipse might not use the c++11 version of the std library?
I've read about the vector class from here. Also, this issue closely resembles the question asked here.
Will provide more info about my environment and such, if needed. Would like to solve this, as it's quite a blocker for my project as of now..
What am I doing wrong? I had no problems compiling and running the code previously to using the std::vector class.
LE: apparently the workaround &(resultWithEvidenceVector.data()+i)->level is recognized by the editor, and the code compiles. Would still like to use the std::vector as it is supposed to be used though.
I had the same problem. It works in Visual Studio compiler but when i try to access vector element i get exactly the same error.
However it seems that if you don't use 'at' then it works for example customStructVector.at(i) use customStructVector(i),
It is strange. I didn't test it in detail. Please note that if you have vector you have to cast the result in order to access the type members.
Regards

How to get rid of strange doxygen warning

When running doxygen over one particular pretty large C-language project consisting many files (all completely documented, I think), then I always find this warning at the bottom of the output:
<#1>:1: warning: parameters of member #1 are not (all) documented
How can I find and remove the trigger of this warning?
Note that the project in question is too large (and the issue not important enough) for bisection or other trial and error based search methods.
Realize this is an old question but just ran into this behaviour myself and didn't find a solution online.
Found the offending file by running Doxygen and looking at where the error message appears in the output (make sure you're not suppressing stdout or you'll just get the error with no context).
In my case the error appeared after the line "Generating dependency graph for group [name]". By looking at the relevant file I found an undocumented, unnamed enum. The members of the enum were still documented. e.g.
enum
{
X = 1, /**< Documented. */
...
}
I'm guessing it's the lack of name on the enum that was throwing Doxygen and causing the unhelpful message. Adding a name causes more helpful error messages to be generated. Documenting the enum (with or without a name) removes the error.

Is it possible to reference a package from not within an import statement?

I'm writing a documentation about a Scala library. When I reference a certain package I do this with a String, e.g. "com.my.example" but would rather prefer to do this in a manner that gives me compile errors if anything breaks (e.g. (com.my.example).mkString).
Of course my IDE will warn me about such situations when refactoring and propose to fix those Strings for me. I'd just prefer to rely on the compiler instead of the IDE. Is this in some way possible? (Creating pseudo classes in each package to reference is not an option).
The compiler doesn't include comments, so it wouldn't break on that. You need to use scaladoc instead of scalac.
When you generate the documentation, you will see warnings for broken references.
For example I misspelled immutable intentionally and got this warning:
[warn] C:\...\Foo.scala:4: Could not find any member to link for "scala.collection.ommutable".
The key thing is to surround your references in double brackets [[ ]], eg:
/**
* This is my link [[scala.collection.ommutable]]
*/
For more info, check out http://docs.scala-lang.org/style/scaladoc.html

ASN.1 compiler with support for Extended XER/RXER

I am desperately searching for an ASN.1 compiler that will successfully parse a predefined ASN.1 definition I got from a customer.
None of the products (free or commercial) so far was able to parse the definition, which is XER based and has some transient RXER dependency - when I specify the relevant ASN.1-definitions manually (taken from the RFCs), the compiler also emits parser errors.
The relevant code line is (simplified):
MYMSG ::= SEQUENCE
{
msgID [ATTRIBUTE] [250] UTF8String OPTIONAL,
msgType UTF8String
}
Every compiler complains about the [ATTRIBUTE] token, so I found this is part of the ASN.X specification defined in RFC 4912 and also depends on support for RXER in RFC 4910, see also X.680-1.
Problem is every compiler I tried does not seem to support these encoding schemas out of the box and fails to parse the definitions mentioned in the RFCs, e.g. for RXER and all definitions that use this encoding I get:
"RXER.asn", line 20
(AdditionalBasicDefinitions): A1139W:
The default encoding reference 'RXER'
for the module
'AdditionalBasicDefinitions' is
unknown and all encoding instructions
within the module identified by this
encoding reference will be ignored.
RXER INSTRUCTIONS
(Note: all dependent modules like ASN.X include the instruction "RXER INSTRUCTIONS" immediately after the "DEFINITIONS"-tag, which is not understood by any compiler I tried).
I tried openasn1 (www.openasn1.org) - funny thing is that I have some old and partially functional Java mapping objects in the code I got that was generated by openasn1! - the online compiler at http://lionet.info/asn1c/asn1c.cgi and various commercial tools like Objective Systems ASN1C v6.4.1 at http://www.obj-sys.com/Cnge641Dwld/acv64kits.php (they even have a current Eclipse plugin), Marben http://www.marben-products.com/asn.1/tce_java.html and unigone http://www.unigone.com/en/products/Asn1Compiler/description
I always get an error similar to this:
ASN.1 grammar parse error near line 13 (token "ATTRIBUTE"): parse error, unexpected TOK_capitalreference, expecting TOK_number
Am I missing something obvious like IMPORTs or other definitions/compiler flags?
I managed to compile the schema and generate the needed Java mapping classes. I had to use the commercial OSS Nokalva compiler, as all free tools I tried failed on (E)XER encoded schemata.
There were also some errors in the schema I received, so here is what I had to do:
first I added the XER-instructions in the DEFINITIONS-line along with the usual Tags
directive:
DEFINITIONS XER INSTRUCTIONS AUTOMATIC TAGS ::=
in the footer, I added the XER encoding directive:
ENCODING-CONTROL XER GLOBAL-DEFAULTS
MODIFIED-ENCODINGS
when using XER encoding, you have to explicitly specify tags to avoid ambiguities in syntax:
[ATTRIBUTE] [TAG: 0]
instead of the ambiguous definition
[ATTRIBUTE] [0]
All these problems were resolved by consulting this nice writeup on EXER-encoding, definitely a good read and thanks to Nokalva for this helpful documentation!