RE: [cdt-dev] Re: traversing the dom

[Andrew Niefer <aniefer@xxxxxxxxxx>]

The CPPVisitor is not a strict superset of the CVisitor.  Off the top of my
head, using the CPPVisitor on C code will miss K&R function declarators as
well as designated initializers.

This does raise the point that the interface will likely need to be
somewhat language independent and there should be a way to get the
appropriate visitor for the dom so the client can doesn't have to handle
each language separately.

-Andrew

cdt-dev-admin@xxxxxxxxxxx wrote on 02/17/2005 11:01:13 AM:

> Hi Andrew,
> great, I missed out on the CPPVisitor! Am I right that using the
> CPPVisitor
> I am ok on plain-c as well?
> The visitor as it is works fine, I use it from the internal package for
> now and switch over to whatever you make public later on. I see the need
> for the public static functions you provide plus the ability to make my
> own derivations from CPPBaseVisitorAction.
>
> Markus.
>
>
> > -----Original Message-----
> > From: Andrew Niefer [mailto:aniefer@xxxxxxxxxx]
> > Sent: Donnerstag, 17. Februar 2005 16:48
> > To: Schorn, Markus
> > Cc: cdt-dev@xxxxxxxxxxx
> > Subject: [cdt-dev] Re: traversing the dom
> >
> > Hi Markus,
> > We do intend to publish an interface, however, I still don't
> > have a good
> > idea about what should be in that interface since we don't
> > yet have any
> > clients.
> >
> > The current CVisitor class has 2 roles, one is to resolve the
> > IBindings
> > associated with each IASTName, and the other is to provide basic tree
> > navigation.  The binding resolution would likely remain
> > internal, clients
> > would access bindings from IASTName#resolveBinding().  The
> > navigation role
> > is the part where some feedback from potential clients would
> > be useful.
> >
> > There is also a CPPVisitor class, which provides the same
> > functionality for
> > C++.  We are trying to keep the implementations for both
> > languages separate
> > so that C can benefit from its being a simpler language.
> >
> > The visit* methods are currently the easiest way to visit the
> > DOM.  You
> > would use runtime types to do it manually, or if you are
> > starting at a leaf
> > node and walking upwards, you can also use the
> > IASTNode.getPropertyInParent().
> > We can add a visitNode method to the current pattern, as well
> > as a kind of
> > getChildNodes if you think that would be more useful.  Feel
> > free to send a
> > patch with what you have in mind.
> >
> > -Andrew
> >
> > "Schorn, Markus" <Markus.Schorn@xxxxxxxxxxxxx> wrote on
> > 02/17/2005 10:18:56
> > AM:
> >
> > > Hi Andrew,
> > > For the purpose of refactoring I have to examine objects
> > implementing
> > > the IAstTranslationIAstCompilation. Due to the large amount
> > of different
> > >
> > > interfaces with different methods to obtain child nodes it is
> > > error-prone
> > > to walk through the full tree. I found that you have implemented the
> > > class
> > > CVisitor for mastering this task.
> > >
> > > My questions:
> > > -------------
> > > * I'd like to use this class, it is internal though. Do you plan on
> > > making it
> > >   available?
> > >
> > > * Using CVisitor I miss out on some nodes. Is this due to
> > the fact that
> > > CVisitor
> > >   handles c-code only? I was playing with c++.
> > >
> > > * Is there another way of getting around in DOM?
> > >
> > >
> > > A suggestion:
> > > -------------
> > > * I'd be of some help to invent a method for IASTNode, that
> > returns all
> > >   nodes contained. That way I could walk the tree without
> > investigating
> > > the
> > >   runtime type of each of the nodes.
> > >
> > > Markus.
> >
> >
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev