[ Yeah, me too… ] Geoff Worboys writes:
Sam Varshavchik wrote:
> I have in a header file, somewhere in /usr/include:
> template<typename T> class vectorObj {
> // blah
> };
> In my header file, that I'm running doxygen on, I have:
> class snorkle : public vectorObj<foobar> {
> // blah
> };
> That's all I have. The snorkle class has Doxygen comments.
> The vectorObj template definition, in /usr/include, has
> Doxygen comments too.
>
> And I get this warning. I could flip WARN_IF_UNDOCUMENTED,
> but I do certainly want to know if something of mine is
> undocumented. But I do not see exactly what needs, or
> should be documented here. All of snorkle's own methods
> are documented. And the template definion in /usr/include is
> also fully documented, including all of its methods. This is
> not a specialization, just a plain old template.
> Having to document vectorObj<foobar>, just because I
> instantiated it with a particular class, sounds weird.
I'm not suggesting you should - I was merely wondering if there
could be something like that might be confusing doxygen (I know
such declarations sometimes confuse me :-)
Have you tried the old comment out everything approach and then
gradually put it back in? With modern editors it is easy to
comment/uncomment a range of lines with "// ". For example if
you reduce your header to simply
//! \brief snorkle is good for breathing under water.
class snorkle : public vectorObj<foobar> {
// // blah
};
Do you get the warning?
Yes, they're still there. The snorkle class is documented already.
Is load(const fd &fdRef) actually being overridden in snorkle or not? And if so, is the override documented?
Nope, not overridden.
The other question that occurs is whether you have turned on INLINE_INHERITED_MEMB (defaults to NO). If occurs to me that if that was yes then the above declaration may be looking for vectorObj<foobar> documentation to inherit, but that class is not part of your doxygen project.
That setting is left unchanged.
Again, I don't know what doxygen should do in this situation, just offering guesses - without an actual working example, guesses are all that can be made.
I've been playing around with this. The problem seems to be that I'm specifying TAGFILES pointing to the tags that include the vectorObj base class that's installed in /usr/include. In other words, this Doxyfile, where the warning is emitted from, has a TAGFILES setting pointing to a tagfile that was generated from the source that installed the vectorObj header file in /usr/include.
If I take out the link to the tagfile, the weird warnings for <unknown>:1 are not emitted. But then I have a slew of others, of course, for all my other \refs to the documentation for the external classes, that are now pointing nowhere.
pgpF4f9gkR3jH.pgp
Description: PGP signature
------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________ Doxygen-users mailing list Doxygen-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/doxygen-users
