headers
Isaac Wagner | 15 Jul 2012 19:26
Picon

doxmlparser won't iterate past "protocol" compound

Hello everyone,

I'm trying to figure out how to use the doxmlparser classes and I've run into a bit of trouble using the compounds() iterator. I have a bit of code like the following:

ICompoundIterator *cli = dox->compounds();
ICompound *comp;

for(cli->toFirst(); comp = cli->current(); cli->toNext())
  {
          std::cout << "Processing " << comp->name()->latin1() << std::endl;
  }

But cli->current() returns 0 when it hits a compound with the kind "prototype." I did a bit of digging and the offending code is in compoundhandler.cpp's CompoundHandler::toICompound() which returns 0 if the compound kind is not a class, struct, union, exception, interface, namespace, file, group, or page. Surely the iterator shouldn't be halted by an unknown type, should it? I think that the best behavior would be to simply skip over compounds which aren't one of these predefined types.

My first thought was to change current() to something like this:

    CompoundEntry *ch = QListIterator<CompoundEntry>::current();

    if(ch && !m_mainHandler->compoundById(ch->id.utf8()))
    {
      toNext();
      return current();
    }
    else
      return ch ? m_mainHandler->compoundById(ch->id.utf8()) : 0;

But that violates the const-ness of current() and doing away with the const would be a very dirty hack (and I'm not actually sure if it would be possible with the inheritance tree).

First I would like to know if this is indeed broken behavior. If it is, what is the cleanest way to solve the problem? I am not particularly familiar with doxmlparser. I'll keep hacking away, but I would love to know if you have any simple solutions to the problem.

Regards,

Isaac
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Doxygen-develop mailing list
Doxygen-develop <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/doxygen-develop
Permalink | Reply | 2 comments |
headers
Isaac Wagner | 15 Jul 2012 19:59
Picon

Re: doxmlparser won't iterate past "protocol" compound

I put together a slightly dirty hack. It could be done a bit clear with the CompoundTypeMap class, and perhaps even cleaner another way, but this solves the problem by simply not including compound types in the list which aren't recognized as one of the subclasses of ICompound. I attached an svn patch if you're interested in merging it or just seeing where I fixed the issue.

On Sun, Jul 15, 2012 at 1:26 PM, Isaac Wagner <isaacbwagner <at> gmail.com> wrote:
Hello everyone,

I'm trying to figure out how to use the doxmlparser classes and I've run into a bit of trouble using the compounds() iterator. I have a bit of code like the following:

ICompoundIterator *cli = dox->compounds();
ICompound *comp;

for(cli->toFirst(); comp = cli->current(); cli->toNext())
  {
          std::cout << "Processing " << comp->name()->latin1() << std::endl;
  }

But cli->current() returns 0 when it hits a compound with the kind "prototype." I did a bit of digging and the offending code is in compoundhandler.cpp's CompoundHandler::toICompound() which returns 0 if the compound kind is not a class, struct, union, exception, interface, namespace, file, group, or page. Surely the iterator shouldn't be halted by an unknown type, should it? I think that the best behavior would be to simply skip over compounds which aren't one of these predefined types.

My first thought was to change current() to something like this:

    CompoundEntry *ch = QListIterator<CompoundEntry>::current();

    if(ch && !m_mainHandler->compoundById(ch->id.utf8()))
    {
      toNext();
      return current();
    }
    else
      return ch ? m_mainHandler->compoundById(ch->id.utf8()) : 0;

But that violates the const-ness of current() and doing away with the const would be a very dirty hack (and I'm not actually sure if it would be possible with the inheritance tree).

First I would like to know if this is indeed broken behavior. If it is, what is the cleanest way to solve the problem? I am not particularly familiar with doxmlparser. I'll keep hacking away, but I would love to know if you have any simple solutions to the problem.

Regards,

Isaac

Attachment (doxmlparser_fix.diff): application/octet-stream, 1199 bytes
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Doxygen-develop mailing list
Doxygen-develop <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/doxygen-develop
Permalink | Reply | 1 comment |
headers
Dimitri Van Heesch | 16 Jul 2012 10:15
Picon
Gravatar

Re: doxmlparser won't iterate past "protocol" compound

Hi Isaac,

I think a somewhat cleaner solution is given by the attached patch. Can you check if that works for you?
Attachment (doxmlparser.patch): application/octet-stream, 2410 bytes

Regards,
  Dimitri

On Jul 15, 2012, at 19:59 , Isaac Wagner wrote:

> I put together a slightly dirty hack. It could be done a bit clear with the CompoundTypeMap class, and
perhaps even cleaner another way, but this solves the problem by simply not including compound types in
the list which aren't recognized as one of the subclasses of ICompound. I attached an svn patch if you're
interested in merging it or just seeing where I fixed the issue.
> 
> On Sun, Jul 15, 2012 at 1:26 PM, Isaac Wagner <isaacbwagner <at> gmail.com> wrote:
> Hello everyone,
> 
> I'm trying to figure out how to use the doxmlparser classes and I've run into a bit of trouble using the
compounds() iterator. I have a bit of code like the following:
> 
> ICompoundIterator *cli = dox->compounds();
> ICompound *comp;
> 
> for(cli->toFirst(); comp = cli->current(); cli->toNext())
>   {
>           std::cout << "Processing " << comp->name()->latin1() << std::endl;
>   }
> 
> But cli->current() returns 0 when it hits a compound with the kind "prototype." I did a bit of digging and
the offending code is in compoundhandler.cpp's CompoundHandler::toICompound() which returns 0 if the
compound kind is not a class, struct, union, exception, interface, namespace, file, group, or page.
Surely the iterator shouldn't be halted by an unknown type, should it? I think that the best behavior would
be to simply skip over compounds which aren't one of these predefined types. 
> 
> My first thought was to change current() to something like this:
> 
>     CompoundEntry *ch = QListIterator<CompoundEntry>::current(); 
> 
>     if(ch && !m_mainHandler->compoundById(ch->id.utf8()))
>     {
>       toNext();
>       return current();
>     }
>     else
>       return ch ? m_mainHandler->compoundById(ch->id.utf8()) : 0;
> 
> But that violates the const-ness of current() and doing away with the const would be a very dirty hack (and
I'm not actually sure if it would be possible with the inheritance tree).
> 
> First I would like to know if this is indeed broken behavior. If it is, what is the cleanest way to solve the
problem? I am not particularly familiar with doxmlparser. I'll keep hacking away, but I would love to know
if you have any simple solutions to the problem.
> 
> Regards,
> 
> Isaac
> 
> <doxmlparser_fix.diff>------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> Doxygen-develop mailing list
> Doxygen-develop <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Doxygen-develop mailing list
Doxygen-develop <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/doxygen-develop
Permalink | Reply | 0 comments |

Gmane