[antlr-interest] Re: ANTLR 3.0 and code generation for C++
Tiller, Michael (M.M.)
mtiller at ford.com
Tue Oct 28 06:41:08 PST 2003
Ric,
This all sounds good to me. You did a pretty good job of listing all the things that I found limiting in the C++ implelementations. My project is relatively small but makes heavy use of heterogeneous ASTs so I would be willing (assuming I have some time) to try out betas or give you feedback on the heteroAST stuff as it becomes available.
--
Mike
> -----Original Message-----
> From: Ric Klaren [mailto:klaren at cs.utwente.nl]
> Sent: Tuesday, October 28, 2003 6:16 AM
> To: antlr-interest at yahoogroups.com
> Subject: Re: [antlr-interest] Re: ANTLR 3.0 and code
> generation for C++
>
>
> Hi,
>
> On Tue, Oct 28, 2003 at 11:06:52AM +0100, Thomas Dudziak wrote:
> > Would it be possible to make the actual char/string type
> configurable ?
>
> It will be configurable to support unicode (char/wchar) so a
> lot of the
> support library will move to templates. To what extend I do
> not know yet
> untill I start playing with a new support lib and a modified
> codegenerator.
> I'll probably create a branch next month when I get some more time.
>
> > Similiarily, it might be feasible to use the boost library
> (shared_ptr
> > etc.) or even a "real" garbage collection lib (like "More for C++",
> > "JUiC++", or the "Boehm-Demers-Weiser Conservative Garbage
> Collector") ?
>
> I plan to do a lot of things the C++ way so we'll probably
> see allocators
> for common objects e.g. plugging in a garbage collector or the boehm
> library or what else should be possible. I'll probably start
> with a simple
> garbage collector for Tokens/AST nodes. No more reference
> counter anyway,
> that's the main goal.
>
> In short my wishlist (if I get to do all of this I'm happy, but no
> guarantees):
>
> - Get rid of the reference counters.
> - More templates, to improve configurability
> - I want to try how far one would get with a very generic
> Token interface
> and some TokenTraits object (compare with char_traits) Then
> maybe see if
> heterogenous tokens are possible.
> - Use a configurable class for Token/AST positions (so the
> designer can choose
> between no token position information, line only, line+column,
> line+colum+file)
> - The same for ASTs (traits+positions) and make heterogeneous
> AST's work.
> - Try to get rid off the exceptions for backtracking and
> error handling (e.g.
> open the way for C codegeneration, and probably significantly boost
> performance, also a good chance to decrease code size)
> - Move a lot of algorithms that are currently hooked to ASTFactory to
> separate functions/templates.
>
> While I work on it there will probably be a number of
> development branch
> releases that will not be able to generate java anymore. I don't know
> enough of the java generics (?) stuff to know if the ideas
> can be ported to
> java.
>
> Ideas? Comments? Suggestions? Declarations of apparent
> insanity of yours
> truly?
>
> Cheers,
>
> Ric
> --
> -----+++++****************************************************
> *+++++++++-------
> ---- Ric Klaren ----- j.klaren at utwente.nl ----- +31 53
> 4893722 ----
> -----+++++****************************************************
> *+++++++++-------
> Words fly like arrows
> as if we knew what was right and wrong. --- Chuang Tsu
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
More information about the antlr-interest
mailing list