Re: [Cpptool-develop] Question for CodeModel...

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

The goal of the CodeModel was to provide an easy way to modify the source=
. I
think it partially succeed: it easier to modify the source, but 'explorin=
g'
the source structure is tricky (dealing with compound statement is not
easy). And, as you point out, it's not easy to maintain.

Having written a nearly complete c++ parser, it is clear for me that this
approach is not realistic in face of the huge amount of diversity of the =
c++
grammar. Those last months, I've being thinking about a new approach to
this. My current idea is as follow:

- have the lexer generate token for all source elements (this includes
spaces and comments)
- have the parser generate an AST that contains all those elements
- have some kind of generic listener/tracker tracks change to the ast, an=
d
impacting the source code when requested.

Refactoring would be implemented using highly reusable micro ast
transformation (instead of a code model). For example, you would have
'insert local variable declaration', 'replace local variable initializer'=
...

I'm currently focusing on getting the parser done (at this time lexer spa=
ces
& comments are discarded).

An issue that is not solved by the above idea is macro handling. It's cle=
ar
that macro should be expanded for correct parsing, but we also need to be
able to track the parameters passed to macro. For example, if a type is
passed to a macro as a parameter, we need to be able to rename the parame=
ter
passed to the macro instead of its expanded instance. Also, some refactor=
ing
may operate on macro (rename macro...), though in this case, it might be
easier to make a specific parser...

Baptiste.

----- Original Message -----=20
From: "Andre Baresel" <and...@gm...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Wednesday, December 17, 2003 10:59 PM
Subject: [Cpptool-develop] Question for CodeModel...


> Hello Baptiste,
>
> i was checking the codemodel/coderewriter sources and i hope i do
> understand now the general
> idea of it. this is enough to do the changes needed to add support for
> the new macro-replacement
> feature. However a general idea arises from looking through the sources
> of code model - what is
> the main reason to have this parallel implementation of all the
> statement/expression/declaration
> elements ? Please correct me if i'm wrong, but I have the feeling that
> this code makes extensions
> and modifications of the ast harder, since the code model needs to be
> synchronized manually
> (error prone...) wouldn't it be possible to integrate the change
> tracking functionality which looks
> very clever :-) ... into the ast ? and reuse the ast - visiting to
> collect the changes ?
>
> Well, my changes to the code model do not affect this ... so in next
> days there'll be the extension
> for code model working with preprocessor.
>
> bye bye
> Andr=E9