What udoc doesn't

Udoc is good enough to be useful to the Oryx team, but has several limitations.

No preprocessor support is not a problem for us at Oryx. Occasionally it's a minor hassle, that's all. This will not change.

No support for nested classes is a problem for us. Single-level nested classes will be implemented when this problem has become sufficiently annoying. Arbitrary nesting is not a priority for us.

No enum support is also a problem for us. We'll fix that sooner or later.

Feeble syntax is an advantage for us, not a bug. There probably are legal function names udoc cannot parse and legal variables it cannot document, but we don't want Oryx code to use that sort of obfuscation. Patches may be accepted, even if we won't use our own time on this.

Lack of index pages isn't a big problem for us; we mostly use the manpage output anyway.

Bad Postscript output is easy to fix. Probably will be improved a day when it's raining and Arnt is uninspired.

Primitive output is almost an advantage. Some improvements may happen, but if there is a conflict between more advanced output and simplicity of use, we prefer simplicity.

Patches are welcome to solve some of the items above (not necessarily all - we do want to keep udoc simple).

For people who prefer something different, we have a list of other similar tools.

Relevant links

About this page

Last modified: 2010-11-19
Location: aox.org/udoc/limitations