I said that there were two issues with doxygen usage to be discussed, but this second one is so minor that actually I don't think we need discuss it, and I wouldn't be writing this if I hadn't said that I would :) .

When documenting the requirements or guarantees of a function, or the invariants of class/struct instance variables, it's common to use operators from mathematics, whether comparison relations (>=, !=), boolean operators (and, or, not, maybe logical implication), set operators (\in, \subseteq, union, intersection), or quantifiers (forall, exists).

Sometimes one would prefer to differentiate between operator!= and mathematical/abstract inequality (e.g. for NaN or for glib data structures commonly referred to with pointers). Similarly, one may wish to use the easier-to-reason-with commutative mathematical and/or operators instead of C/C++'s short-circuiting &&/|| (or `&&', to use doxygen quoting!).

In javadoc, which I'm more accustomed to, the natural solution is to use HTML character entity references (`∧', `∈', `≥' etc.) -- partly because HTML supports them, and partly because the alternative escaped representations (`&&', `>=') are worse.

However, doxygen doesn't currently accept many of these -- see http://sourceforge.net/tracker/index.php?func=detail&aid=1018462&gro... which also discusses alternatives.

Unlike HTML/JavaDoc, Doxygen does allows backslash to be used for escaping, which eases things a little.

Probably for the moment we'll stick with backslash escaping or keeping the words in the generated documentation rather that using symbols. Has an advantage that people are more likely to understand forall/exists/&&/|| than the corresponding symbols ∀/∃/∧/∨ (upside-down A, backwards E, upside-down v, right-way-up v).

pjrm.