[antlr-interest] FEATURE REQUEST: std::stream -- remove

Ric Klaren klaren at cs.utwente.nl
Mon Feb 16 09:14:33 PST 2004


Hi,

On Sun, Feb 15, 2004 at 09:23:08AM +0200, Ruslan Zasukhin wrote:
> Rick, you are going to develop now new C++ sources as I know.

I'm still planning on rewriting it. Mainly to support Unicode and make it
more C++ style.

> So I dream, that ANTLR C++ runtime sources of Lexer / Parser
> depend NOT on std::streams, but on some C++ interface class of stream

Actually only the default CharBuffer relies on std::istream. The lexer
only uses InputBuffer mechanics to access it's input.

>     I_Istream
>     I_OStream
> 
> And ANTLR distribution have include implementation of these interfaces for
> STD::stream.
> 
> 1) STD::streams will be encapsulated into this .cpp file only
> 
> 2) we will get ability to use other implementations of streams if we need.
> 
> For example, in our Valentina DBMS we have own such stream interfaces,
> And we have a lots of implementations of them
>     Stream on STD file
>     Stream on our own file class
>     Stream on socket
>     Stream on Cached Files.
> 
> As you know DBMS have caching, and we can use files via our own caching.
> But because ANTLR depend on std::stream we cannot use caching files with it.

Erm why not write a custom InputBuffer for your caching stream (or for your
particular stream wrapper baseclass)? Have a look at the CharInputBuffer
for a simple example.

There are still many unknowns for the C++ support lib rewrite. I still have
to research unicode more. I would prefer not to make antlr depend on a
third party library (like IBM's unicode lib) but this may be unavoidable to
get good unicode support. I suspect there will be some template use to plug
different string backends into the lib (so people can easily have a 'lite'
version or a heavier 'unicode' version, I also see room for performance
improvements here with tweaks to the codegen and template parameters) 
Adding stream wrappers in this mix might be possible but it could well be
that they will complicate things.

It seems that the choice within your company to move out of the way of
streams is mostly due to cross vendor STL/compiler support. While I can
understand this decision I'm not sure wether its a good idea for antlr.
Eventually compilers and standard library will improve up to a point that
the issues you mentioned will dissapear. I'd rather engineer towards the
standard than towards making an own standard.

So in short I'd have to give a logical maybe as answer, adding/using
wrappers per default I'd rather not do. Making it easier to plug such
wrappers into antlr is not a problem (as long as they're sane and it does
not complicate things).

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



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/antlr-interest/

<*> To unsubscribe from this group, send an email to:
     antlr-interest-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/
 



More information about the antlr-interest mailing list