CEDET

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 
following function:

bool parse_definition(std::string const &file_name, parse_cb_t cb);

---%<---
Token->text function tests:
semantic-name-nonterminal:
  parse_definition
semantic-abbreviate-nonterminal:
  parse_definition()
semantic-summarize-nonterminal:
  Functions: bool parse_definition (const std::string 
file_name,parse_cb_t cb)
semantic-prototype-nonterminal:
  bool parse_definition (const std::string file_name,parse_cb_t cb)
semantic-concise-prototype-nonterminal:
  parse_definition (std::string,parse_cb_t)
semantic-uml-abbreviate-nonterminal:
  +parse_definition : bool
semantic-uml-prototype-nonterminal:
  +parse_definition (file_name : std::string,cb : parse_cb_t) : bool
semantic-uml-concise-prototype-nonterminal:
  +parse_definition (std::string,parse_cb_t) : bool
semantic-prin1-nonterminal:
  ("parse_definition" function ("bool") (("file_name" variable 
"std::string" nil ((const . t)) nil nil #<overlay from 684 to 713 in 
parse_mab_kat.hpp>) ("cb" variable "parse_cb_t" nil nil nil nil 
#<overlay from 714 to 728 in parse_mab_kat.hpp>)) ((prototype . t)) 
nil nil #<overlay from 662 to 729 in parse_mab_kat.hpp>)
--->%---

Does this look ok to you?

I just discovered another issue with typedefs. Normal typedefs are 
parsed correctly, but a typedef for a function pointer isn't.

For example:

typedef bool (* foo_t)(int const &);

gives the followinng output:

---%<---
Token->text function tests:
semantic-name-nonterminal:

semantic-abbreviate-nonterminal:
  bool.
semantic-summarize-nonterminal:
  Attributes: foo_t
semantic-prototype-nonterminal:
  foo_t
semantic-concise-prototype-nonterminal:

semantic-uml-abbreviate-nonterminal:
  + : foo_t
semantic-uml-prototype-nonterminal:
  + : foo_t
semantic-uml-concise-prototype-nonterminal:
  + : foo_t
semantic-prin1-nonterminal:
  ("" variable "foo_t" nil nil nil nil #<overlay from 827 to 833 in 
parse_mab_kat.hpp>)
--->%---

Markus

Berndl, Klaus wrote:

One more thing I just discovered:

> **** Template-specifier can now contain normal args like "int i" which is very
>      important.

template <int i> struct foo { }; // ok

foo<0> bar; // not ok

---%<---
Token->text function tests:
semantic-name-nonterminal:
  bar
semantic-abbreviate-nonterminal:
  bar
semantic-summarize-nonterminal:
  Variables: int bar
semantic-prototype-nonterminal:
  int bar
semantic-concise-prototype-nonterminal:
  bar
semantic-uml-abbreviate-nonterminal:
  +bar : int
semantic-uml-prototype-nonterminal:
  +bar : int
semantic-uml-concise-prototype-nonterminal:
  +bar : int
semantic-prin1-nonterminal:
  ("bar" variable "int" nil nil nil nil #<overlay from 373 to 377 in 
main.cpp>)
--->%---

Markus

>>> =?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 
>following function:
>
>bool parse_definition(std::string const &file_name, parse_cb_t cb);
>
>---%<---
>Token->text function tests:
  [ ... ]
>semantic-prototype-nonterminal:
>  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
issue.

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
smart completion.


>I just discovered another issue with typedefs. Normal typedefs are 
>parsed correctly, but a typedef for a function pointer isn't.
>
>For example:
>
>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

-- 
          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