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

Ruslan Zasukhin sunshine at public.kherson.ua
Mon Feb 16 10:02:22 PST 2004


on 2/16/04 7:14 PM, Ric Klaren at klaren at cs.utwente.nl wrote:

>> 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.

Hi Rick,

I already have answer this --
    we AVOID usage of STD classes in our project.
    on several reasons.

Only ANTLR MAKE us to include them.
And only in part of project where ANTLR present we use them.


> There are still many unknowns for the C++ support lib rewrite. I still have
> to research unicode more.

We have made this work already for our Valentina database.
I believe that the best way -- IBM ICU library.

It works with all compilers and all platforms, Is free, open source.
It is best of the best. Even Apple have integrate it into latest MacOS 10.3


> 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.

Yes. Especially IF you think about many platforms and many compilers.
Or you must write own wrappers for EACH OS.
No guarantee that ALL Oses work in the same way.

> 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.

NOT COMPLICATE!

We already have done a lots of such work in Valentina.
I will be happy share with you our experience,
And our Unicode and stream sources.

> 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 whether its a good idea for antlr.

Look. 

ANTLR still will work with STL !!!

Just STL class (streams and string) will be wrapped by FAÇADE interface.
ANTLR loose nothing!

But it win that EVERYBODY ELSE can make own implementation of new ANTLR
interface classes using something else than STD.

May be somebody works with wxWindows. This great framework have own String
class and own Streams. So why SOMEBODY must be forced also add to own
project STL classes???

And now we are FORCED to include STL classes because ANTL CANNOT be tuned to
avoid them. You see?

It needs just add SMALL interface classes

    I_Stream
    {
        read_char() = 0;
        write_char() = 0;
    };


And make all ANTLR code depended ONLY on this interface.

Again, I am sure that ANTLR use quite few calls to streams and to strings.
So you will need just 30-60 minutes to make IMPLEMENTATION of interfaces
around STL.


> 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).


-- 
Best regards,
Ruslan Zasukhin      [ I feel the need...the need for speed ]
-------------------------------------------------------------
e-mail: ruslan at paradigmasoft.com
web: http://www.paradigmasoft.com

To subscribe to the Valentina mail list go to:
http://lists.macserve.net/mailman/listinfo/valentina
-------------------------------------------------------------



 
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