>>> =?ISO-8859-1?Q?Markus_Sch=F6pflin?= seems to think that:
>Berndl, Klaus wrote:
>> A new C++/C parser is available in CVS (just download latest semantic-c.el
>> from branch v1p4)
>> Now also wide-char types and literals are parsed correct.
>Yes, I can verify this. Thank you very much for your work!
>About the reference issue, what do you think about the output for the
>bool parse_definition(std::string const &file_name, parse_cb_t cb);
>Token->text function tests:
[ ... ]
> bool parse_definition (const std::string file_name,parse_cb_t cb)
[ ... ]
>Does this look ok to you?
It looks as I would expect, knowing which bugs already exist.
The main problem is just that C++ does things the original token
structure was not designed to do. Specifically, it tries to
differentiate between the type (like "int") and the declaration
modifiers, which seem to appear in all sorts of random places. Many
of these modifiers are now parsed correctly, but ignored due to this
C++ basically needs to redefine the token structure for it's own
purposes for this to work. Unfortunately, doing so makes it hard for
a generic tool to do a good job making UML diagrams, or performing
>I just discovered another issue with typedefs. Normal typedefs are
>parsed correctly, but a typedef for a function pointer isn't.
>typedef bool (* foo_t)(int const &);
>gives the followinng output:
[ ... ]
Function pointers are currently not supported at all. The rule
`varname' would have to be updated, and changes would also be needed
in semantic-expand-c-nonterminal would then have to label things
appropriately. Once that is done, appropriate token->text functions
would need override methods. Nifty questions could then be asked, is
a function pointer in a struct a virtual method? The UML output
routines want to know. ;)
Eric Ludlam: zappo@..., eric@...
Home: http://www.ludlam.net Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org