Reverse engineering the attached files causes an
"argument list too complex" error. Stepping through
the parsing code it appears that the scoped return
value is causing the parser to get confused about where
the function name begins.
I am currently writing a new version of the parser. The current
version does not support change to well. Fix one bug, get two
more in it's place. For example the change you suggest may
work for the code you are dealing with but code containing a lot
of scope operators ("::") may fail. This parser came from
wxWidgets (wxWindows) and I found myself always plugging
holes in the code and one of those hole was and still is the scope
operator. Thanks for the suggestion, it may be better to break
the code where it works for that one case it works for the scope
operator than to have it not work on majority of the other parsed
source code,
Thanks again for your help,
Gunner
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The change i suggested worked very good on
reverseengineering quite complex project written by multiple
authors. It also seemingly fixed bug reported as[675347] too.
I overall agree that the parser in this project is not most
powerful or maintainable one. The major problem is that
classbuilder does not seemingly support nested
classes/namespaces etc. If your new parser will do it then its
good idea to work on it. Even horrible end may be better than
endless horror. ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Too Complex
Logged In: YES
user_id=109050
The current parser will probably be replaced with something
better, the current one is to difficult to work with.
Logged In: YES
user_id=698026
C++ parser is complex piece of software anyway ... replacing
it takes time.
For people who dont want to wait I got a fix or at least current
one stopped throwing these exceptions if i did it.
ClassBuilder.dll!SourceParser::ParseFunction Line 1125
WAS:
while( *cur != '(' && *cur != ':')
FIX:
while( *cur != '(' /*&& *cur != ':'*/)
Nearby comments indicate that looking for ":"-s is probably
bug anyway.
Logged In: YES
user_id=109050
I am currently writing a new version of the parser. The current
version does not support change to well. Fix one bug, get two
more in it's place. For example the change you suggest may
work for the code you are dealing with but code containing a lot
of scope operators ("::") may fail. This parser came from
wxWidgets (wxWindows) and I found myself always plugging
holes in the code and one of those hole was and still is the scope
operator. Thanks for the suggestion, it may be better to break
the code where it works for that one case it works for the scope
operator than to have it not work on majority of the other parsed
source code,
Thanks again for your help,
Gunner
Logged In: YES
user_id=698026
The change i suggested worked very good on
reverseengineering quite complex project written by multiple
authors. It also seemingly fixed bug reported as[675347] too.
I overall agree that the parser in this project is not most
powerful or maintainable one. The major problem is that
classbuilder does not seemingly support nested
classes/namespaces etc. If your new parser will do it then its
good idea to work on it. Even horrible end may be better than
endless horror. ;-)
Logged In: YES
user_id=698026
BTW ... there are several quite sophisticated open source
C++ parsers available so maybe better try to embed one of
them, instead of writing new one.
Logged In: YES
user_id=109050
I have looked at some of these parsers and you end up having to
write description of C++ to the parser.
I looked at the code you mention and it deals with some code in
wxWindowl