[antlr-interest] FEATURE REQUEST: std::stream -- remove
klaren at cs.utwente.nl
Tue Feb 17 02:45:15 PST 2004
On Mon, Feb 16, 2004 at 08:02:22PM +0200, Ruslan Zasukhin wrote:
> > 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.
> 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.
Moving 100% away from STL is not an option. You will have to keep a local
modified copy of ANTLR to get that. It is probably quite easy to make a
sed/perl/tcl script that patches the antlr runtime to use whatever
replacements you want (as long as they're STL'ish enough)
Although you seem to have missed the point of the custom InputBuffer (as
Loring pointed out). You will have to do a little bit more work to
initialize a lexer see for an example the calc example, one of the Main.c's
in it uses a different InputBuffer. You may have to remove the convenience
constructor from the lexer that uses a istream but that's a trivial change.
Not using istreams is easy even in the current runtime.
> > 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
This is indeed the best candidate I've seen so far. But requiring it by
default is excessive.
> > 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.
> 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?
You're free to modify the ANTLR runtime. So forced is a big word. A facade
will mean that in all kinds of places an extra indirection will happen. I'd
rather use templates for this.
I don't particularly see it as a benefit of a library to use it's own
homecooked implementations of streams/vectors/whatever. C++ is about to
move out of that stone-age era. It looks like that even the biggest STL
saboteur (Microsoft) finally made a decent compiler and with the many
platforms gcc is available on people should not have an excuse to use a
stone-age compiler/stdlib. Now we can only pray that Microsoft switches to
ELF and gets rid of the bad joke called DLL's then I'll be happier.
> And make all ANTLR code depended ONLY on this interface.
I'd suggest you have a look at InputBuffer.hpp and friends. It's basically
what you suggest.
Moving away from std:string does not really appeal to me. Making the string
class configurable via template parameters will almost certainly happen in
a runtime rewrite. Then again patching std::string out of the runtime with
a sed/perl/tcl script is probably doable in an hour.
---- Ric Klaren ----- j.klaren at utwente.nl ----- +31 53 4893722 ----
Time what is time - I wish I knew how to tell You why - It hurts to know -
Aren't we machines - Time what is time - Unlock the door
- And see the truth - Then time is time again
From: 'Time what is Time' by Blind Guardian
Yahoo! Groups Links
<*> To visit your group on the web, go to:
<*> To unsubscribe from this group, send an email to:
antlr-interest-unsubscribe at yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
More information about the antlr-interest