Re: [Cpptool-develop] Declaration parsing started...

[Baptiste L. <gai...@fr...>]

Wouah, you're fast. This sound very promising.

Notes that concerning the function pointer, the most important place to
support them is typedef. In most of the code I have seen, function pointers
were nearly always 'typedefed'.

Concerning code clean-up, you might want to reuse the SourceBuilder class we
use in the rfta library (or implement a similar class, more dedicated to ast
node range). This would makes the tests easier to write, read and maintain.

Baptiste.

----- Original Message -----
From: "Andre Baresel" <and...@gm...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Friday, April 25, 2003 8:50 AM
Subject: Re: [Cpptool-develop] Declaration parsing started...


> Baptiste Lepilleur wrote:
>
> >I'll give this a more thorough look later on. A few primilary remarks
> >though:
> >
> >Our 'C++' is wider than the standard (we have single pass parsing). For
> >example, we should support class declaration such as:
> >
> >class RFTA_API TextDocument { };
> >
> >Were RFTA_API is stored as the optional 'export macro name'. This is a
> >widely used idiom on Win32.
> >
> >The AST should capture all data required for the source code manipulation
> >(capture the range of all element that might be removed, inserted,
> >modified).
> >
> >A primary goal would probably be able to identify the function/method
bodies
> >(this would solve the issue you raised concerning the starting compound
> >statement for variable declaration search).
> >
> This works allready, I'm currently at the point of parsing declaration
> specifiers and declarators. The parsing of
> specifiers includes class declarations. About the declarators I'm not
> yet sure how far I should go. At the moment
> I try to merge the variabledeclmutator with my declarationmutator and
> try to get a more general solution which
> can parse any declaration type.
> There's only one problem left which are function pointers like:
>    usertype (*f) ( int );
> As soon as I have cleaned the code I will check in.
>
> >Next, I would probably go for class parsing (rough, just extract the
name,
> >methods, and method/function implementation parsing. Having those two
open
> >doors for ExtractInterface refactoring (just needs the class methods),
and
> >ExtractMethod refactoring (need to add a method in the class declaration,
> >adding a new method body, and know what are the method parameters).
> >
> This is fine with the current implementation.
>
> until later,
> André