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

[lgcraymer]

Ruslan--

I think that you misinterpreted Ric's comment on InputBuffer.  The
dependency on streams does not occur until CharInputBuffer (an
InputBuffer subclass).  It would not be difficult to comment out the
istream constructors and use a custom InputBuffer subclass that does
not use streams.

Getting rid of std::string would be another matter--doable, but
probably not worth it.  Personally, I think that the decision to avoid
use of the standard library will bite you--I've been dealing with a
messy legacy application which predates the C++ standard and had no
template code before I introduced ANTLR.  There are many places where
an upgrade to using the standard library would have simplified the
code, and the classes written to provide string--there are two string
classes, neither of which is quite compatible with std::string--and
other capabilities complicate the maintenance problem.

As Ric points out, C++ compiler technology and standards compliance is
improving, and conformance has gotten pretty good.  Rather than
phasing out use of standard components from ANTLR, you might be better
off with a plan for phasing STL elements into Valentina to improve
maintainability as compiler maturity can be demonstrated.  It would
not be too difficult to come up with an adequate test suite for the
standard capabilities that you need supported by the compiler and
libraries.  Maintainability is a tough issue, and avoidance of
standard capabilities in favor of home-grown (proprietary) solutions.
 What happens when you and the other original developers move on?

--Loring

--- In antlr-interest at yahoogroups.com, Ruslan Zasukhin <sunshine at p...>
wrote:
> on 2/16/04 7:14 PM, Ric Klaren at klaren at c... 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 p...
> 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/