[antlr-interest] advocacy of C++ support in ANTLR 3.x

[Jim Idle]

If this cannot be don't now, then it is a mistake in the generating templates as that is what is supposed to happen, so I will look into it. Perhaps I have left some casts in the templates.

Jim

> -----Original Message-----
> From: Gavin Lambert [mailto:antlr at mirality.co.nz]
> Sent: Wednesday, April 02, 2008 1:06 PM
> To: Jim Idle; ANTLR
> Subject: Re: [antlr-interest] advocacy of C++ support in ANTLR 3.x
> 
> At 06:23 3/04/2008, Jim Idle wrote:
> >The adaptor is an adaptor, or the default tree nodes would not
> >work, but in C there is no class inheritance and I cannot protect
> >functions/pointers that must be public, from being used anywhere.
> >The Java version of the tree node also has addChild etc. It needs
> >to because the tree adaptor needs to ask it to add children.
> >However, if you don't call the treenode methods, then they won't
> >be used directly in either C or Java or any other target.
> 
> I think Tom's point is that in the Java version the tree nodes are
> simple objects, and the adaptor class is the only known interface
> -- you ask the adaptor class to create a node, to add a child to a
> node, etc, but when an actual node is referred to it's always an
> 'object', not a 'CommonTreeNode'.  The grammar generated code
> never directly touches the tree nodes themselves.
> 
> This same approach ought to still be possible in C -- substituting
> 'void *' for 'object' and adding some memory tracking/disposal
> semantics, of course.
> 
> So the default ANTLR3_COMMON_TREE_ADAPTOR creates and manipulates
> ANTLR3_COMMON_TREE objects, but the interface specified by
> ANTLR3_BASE_TREE_ADAPTOR only ever uses 'void *'.  This means that
> a user can completely reimplement the interface to use their own
> custom node type totally divorced from ANTLR.  The
> ANTLR3_BASE_TREE structure simply goes away, as it's no longer
> useful.  (Or maybe you could still have two levels; one which
> implements the basic tree semantics and one that adds the token
> payload.  But I'm not sure that's especially useful.)