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

Ruslan Zasukhin sunshine at public.kherson.ua
Mon Feb 16 23:32:46 PST 2004


on 2/17/04 4:16 AM, lgcraymer at lgc at mail1.jpl.nasa.gov wrote:

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

Hmm,

As far as I see, in the constructor of Lexer we must give stream.

I have code in our project

Importer_Text::Importer_Text(
    I_Table_Ptr            inTable,
    I_Location_Ptr         inLocation,
    Const_I_PropertyContainer_Ptr inProperties )
:    
    mTable( inTable ),
    
    mStream( U2A( inLocation->get_Path() ).c_str() ),           <<<<<
    mLexer( mStream )                                           <<<<<
{
    ProcessProperties(inProperties);
}


Where 
        STD::ifstream         mStream;

But I will look more deeply on what you mean.
May be I miss that point.

> Getting rid of std::string would be another matter--doable, but
> probably not worth it.

Well, we use IBM ICU library, so we have unicode class String from ICU.
And therefore we DO NOT use std::string anywhere in the project.
Only place where we are FOCRED to do this -- ANTLR

Do you think it is good design of framework (I mean ANTLR)
If I cannot tune it?  IMHO this means BAD OO design.

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

Let me explain. Valentina database is famous by its SPEED.
We fight here for performance of each byte of code.

STL is great for development of general kind apps, with GUI,
Where size and speed not critical. But this is not a case for DBMS.
We want control every byte of code we write. We cannot depend on
implementation of particular compiler vendor.


> There are many places where an upgrade to using the standard library would
> have simplified the code,

We do have simple code.


Again we do HUGE project. And we take care SELF about utility classes that
simplify our life and coding. We have own arrays, strings, trees, streams.
They are highly optimized for our needs and tasks.

We use templates and interfaces. We use smart ptr and templates driven by
policies. We study all modern C++ concepts and tips, STL and BOOST.

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

And correct. WE ARE FORCED now to have in our projects 2 classes
    std::string -> ANTLR
    IUC::String -> ICU

We are FORCED to do conversions between them when we send data to/from
ANTLR. Not pleasant. I want to be able to say to ANTLR in some way:
    Please use ICU::String class in ANTLR RUNTIME code.
    Please use UChar instead of char to support Unicode.
 
BTW, this is where idea of Rick to use TEMPLATED in ANTLR can work!!!
We can make template parameters

        TCHAR
        prefix  L"Unicode string"       "Not unicode string"
        class string

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

AGAIN! I DO NOT ask REMOVE STL from ANTLR !!!!!!!

I just ask WRAP it by façade -- interface.
I.e. To use ideas of COM/CORBA technologies -- ANOTHER STANDARD.

I do not ask move away FROM STANDARD!
I ask just use BOTH MODERN STANDARDS:  templates AND interfaces.

Such combination is MUCH MORE powerful than just one of them.


> you might be better
> off with a plan for phasing STL elements into Valentina to improve
> maintainability as compiler maturity can be demonstrated.

If I will do this, Valentina will become 10-50 times slower.
This is not serious.

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

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