Use "\return" as "\brief" - doxygen

For very simple functions I would like to only have a \return section, but still show it as brief. (How) Can this be done?
For example:
/**
\return The distance.
*/
template <typename R = int64_t>
R distance(const pcg32 &other);
this generates no \brief in the docs, whereas e.g. this does:
/**
Multi-step advance function (jump-ahead, jump-back).
\param distance the distance.
*/
template <typename T>
void advance(T distance);
See this screenshot:

I believe that the brief section is meant to hold single paragraphs, while the \return command actually generates a header along with a paragraph.
In order to avoid changing any global REPEAT_BRIEF settings, I'd suggest a simple macro to be used for this case, e.g.,
Add the following to the doxygen ALIASES configuration:
"briefreturn=**Returns** "
Use in your description comment like so:
/** \briefreturn the value that it returns */
int foo();
This would give you a one-line brief that is similar to the multi-line output from \return.
Modifying the macro, you can achieve other behaviors as desired, e.g., forcing generation of a details section, even when no other details supplied but the return:
"briefreturn{1}=**Returns** \1 \details. "
This can still be followed by details in the normal manner. Note that will have a leading ".", though. (Perhaps some other non-whitespace character can be used instead that is less offensive as a leading sentence character)

Related

How can I know if a character will fit into the grid, and if it won't, how many spaces it needs?

With ncurses, how can I know whether or not a certain character will fit into the grid? I assume that this is font-dependent and am not sure at all how to do it.
So in the above example, the function I am looking for would:
grid_spaces_per_char(L"字") => 2
grid_spaces_per_char(L"G") => 1
grid_spaces_per_char(L"😇") => 2
grid_spaces_per_char(L"Q") => 1
grid_spaces_per_char(L"。") => 2
I need to know this so that I can implement word wrapping in a UTF-8 aware C++ Slack ncurses application.
If it cannot be done with ncurses alone, what should I do instead to get this information?
wcwidth is only part of the solution: ncurses expands control characters (other than whitespace) into two characters. The "easy" way to do this is to write the character onto a window which is not displayed, and use the position before/after to find the actual width which ncurses would use on the visible (refreshed) windows. A window can be created, used for a workspace and deleted without affecting what is shown on the screen.
That technique is used in Lynx,
/*
* Determine the number of cells the given string would take up on the screen,
* limited (in the case of wide characters) by the maxCells parameter.
*
* If the returnCellNum parameter is TRUE, return the number of cells;
* otherwise, return the length (limited by the len parameter) of the prefix of
* the string that fits in maxCells cells.
*/
as well as the ncurses-examples program view, which comments
/*
* Use the curses library for rendering, including tab-conversion. This
* will not make the resulting array's indices correspond to column for
* lines containing double-width cells because the "in_wch" functions will
* ignore the skipped cells. Use pads for that sort of thing.
*/
By the way:
wcwidthgives different results on different systems, and it may not actually correspond to what is shown on the terminal. That is a limitation due to the way standards are introduced, and rather than building one on top of another, there are conflicting interpretations, incomplete documentation, etc.
It should also be (but apparently is rarely) locale-dependent since some characters have different widths in different locales. In xterm, both issues come to play with line-drawing
/*
* Solaris 10 wcwidth() returns "2" for all of the line-drawing (page
* 0x2500) and most of the geometric shapes (a few are excluded, just
* to make it more difficult to use). Do a sanity check to avoid using
* it.
*/
and soft-hyphens
/*
* Regarding the soft-hyphen aberration, see
* http://archives.miloush.net/michkap/archive/2006/09/02/736881.html
*/
I've found the answer myself by using some different keywords -- the answer is to use wcswidth or wcwidth found in wchar.h.
There are some caveats, for example, Windows does not include this function, and it can sometimes be out of date. More caveats explained here and here.

How to search for any unicode symbol in a character string?

I've got an existing DOORS module which happens to have some rich text entries; these entries have some symbols in them such as 'curly' quotes. I'm trying to upgrade a DXL macro which exports a LaTeX source file, and the problem is that these high-number symbols are not considered "standard UTF-8" by TexMaker's import function (and in any case probably won't be processed by Xelatex or other converters) . I can't simply use the UnicodeString functions in DXL because those break the rest of the rich text, and apparently the character identifier charOf(decimal_number_code) only works over the basic set of characters, i.e. less than some numeric code value. For example, charOf(8217) should create a right-curly single quote, but when I tried code along the lines of
if (charOf(8217) == one_char)
I never get a match. I did copy the curly quote from the DOORS module and verified via an online unicode analyzer that it was definitely Unicode decimal value 8217 .
So, what am I missing here? I just want to be able to detect any symbol character, identify it correctly, and then replace it with ,e.g., \textquoteright in the output stream.
My overall setup works for lower-count chars, since this works:
( c is a single character pulled from a string)
thedeg = charOf(176)
if( thedeg == c )
{
temp += "$\\degree$"
}
Got some help from DXL coding experts over at IBM forums.
Quoting the important stuff (there's some useful code snippets there as well):
Hey, you are right it seems intOf(char) and charOf(int) both do some
modulo 256 and therefore cut anything above that off. Try:
int i=8217;
char c = addr_(i);
print c;
Which then allows comparison of c with any input char.

"error: unclosed comment" in multiline comments

When converting a template from Java to Scala, I've noticed the following quirk with multiline comments that can be reduced to the following snippet:
/**
* /*
*/
class Blah {}
The above fails to compile with "error: unclosed comment", while being valid in Java.
This proves problematic, since it makes it harder to document e.g. acceptance of glob-type strings (e.g. "requires a path like something/*.myformat").
Is this a bug or a feature?
It is, in fact, a feature. To quote Section 1.4 of the Scala Language Specification:
A multi-line comment is a sequence of characters between /* and */.
Multi-line comments may be nested, but are required to be properly
nested. Therefore, a comment like /* /* */ will be rejected as having
an unterminated comment.
(emph. mine)
Fortunately, it's relatively easy to work around in the case you need it (like the glob example from the question) by escaping the / or * literal, netting something like:
/**
* /*
*/
which displays correctly in the generated Scaladoc.

Can actions in Lex access individual regex groups?

Can actions in Lex access individual regex groups?
(NOTE: I'm guessing not, since the group characters - parentheses - are according to the documentation used to change precedence. But if so, do you recommend an alternative C/C++ scanner generator that can do this? I'm not really hot on writing my own lexical analyzer.)
Example:
Let's say I have this input: foo [tagName attribute="value"] bar and I want to extract the tag using Lex/Flex. I could certainly write this rule:
\[[a-z]+[[:space:]]+[a-z]+=\"[a-z]+\"\] printf("matched %s", yytext);
But let's say I would want to access certain parts of the string, e.g. the attribute but without having to parse yytext again (as the string has already been scanned it doesn't really make sense to scan part of it again). So something like this would be preferable (regex groups):
\[[a-z]+[[:space:]]+[a-z]+=\"([a-z]+)\"\] printf("matched attribute %s", $1);
You can separate it to start conditions. Something like this:
%x VALUEPARSE ENDSTATE
%%
char string_buf[100];
<INITIAL>\[[a-z]+[[:space:]]+[a-z]+=\" {BEGIN(VALUEPARSE);}
<VALUEPARSE>([a-z]+) (strncpy(string_buf, yytext, yyleng);BEGIN(ENDSTATE);} //getting value text
<ENDSTATE>\"\] {BEGIN(INITIAL);}
%%
About an alternative C/C++ scanner generator - I use QT class QRegularExpression for same things, it can very easy get regex group after match.
Certainly at least some forms of them do.
But the default lex/flex downloadable from sourceforge.org do not seem to list it in their documentation, and this example leaves the full string in yytext.
From IBM's LEX documentation for AIX:
(Expression)
Matches the expression in the parentheses.
The () (parentheses) operator is used for grouping and causes the expression within parentheses to be read into the yytext array. A group in parentheses can be used in place of any single character in any other pattern.
Example: (ab|cd+)?(ef)* matches such strings as abefef, efefef, cdef, or cddd; but not abc, abcd, or abcdef.

What is '`' character called?

I feel silly for asking this but it isn't like I could google this.
What is the ` character called? In case it doesnt show up, it is the character used for inline code with markdown. Also, on most keyboards, it shares the key with ~.
I like all three answers so I made this a CW instead of accepting
All sorts of things, but in programming mostly the back-quote or backtick,
Grave (pronounced Grahv, not like the synonym for tomb) or Grave accent.
From the Jargon file, the prime nerd reference which really should be an ISO standard :-)
Common: backquote; left quote; left single quote; open quote; ; grave.
Rare: backprime; backspark; unapostrophe; birk; blugle; back tick; back glitch; push; opening single quotation mark; quasiquote.
You can use Unicode table to find name of the symbol. There are utilities which let you search it, like gucharmap. It gives U+0060 GRAVE ACCENT for this symbol.
This answer or this answer provides a good definition.
In laymen's terms "no-shift-tilde" is also useful in PHP for keeping mySQL statements from crashing on single quotes on the table name.
SELECT * from `the_table_name` WHERE id=1 // best practice
For some reason certain PHP servers will choke on this:
SELECT * from 'the_table_name' WHERE id=1 // not preferred method
This normally works, but doesn't pass nice in strings:
SELECT * from "the_table_name" WHERE id=1 // how to escape this string?
Other than that, I don't use it much.