Re: Any interest for a parser class?

From: rogeeff (rogeeff_at_[hidden])
Date: 2002-01-17 15:40:30

--- In boost_at_y..., Dan Nuffer <dnuffer_at_c...> wrote:
> rogeeff wrote:
> 
>  >>>* I was not able to find out portability report for Spirit. 
Since
>  >>>CLA
>  >>>parsing is very basic facility, I should be able to compile it 
on
>  >>>majority of compilers.
> 
> 
>  >>This _is_ an issue with Spirit.  The developers are working on 
it.
>  >>IMHO braindead compilers should not direct the design of 
libraries,
>  >>though of course every effort should be made to support them if
>  >>at all possible.
> 
> 
>  >CLA parser is very basic facility. It *should* compile on 
majority of
>  >compilers.
> 
> 
> 
> Joel already posted which compilers we know Spirit works with.  The 
only 
> compiler I know of that the current code does not work with is 
MSVC. An 
> MSVC port should be possible, just that no one's done it yet.
> Joel is going to a lot of work to make sure it works with Borland.

I am not able to compile version 1.3 not with MSVC nor with SunPro CC 
Forte6u2. Mor over when I am trying to compile your simpliest example 
calc1.cpp on my ultra 5(400) I took more then 10 seconds before it 
finished compilation and generated some errors. How long will it take 
to compile completely I do not know.

[...]

>  >If I got properly from your code below, Spirit support distributed
>  >definitions. But this make me move spirit.hpp into the header 
file to
>  >be able to provide an interface register_cla( rule<> ... ). Now 
Spirit
>  >is inherited by my users and is not implementation detail.
> 
> 
> No, you can include spirit_fwd.hpp in your header, which is < 100 
lines 

~200 (v1.3)

Plus it includes tuples, so altogether we got ~60k of includes. 
Anyway It would not help since user will need to include spirit.hpp 
themself since they will need to implement parsing using Spirit

> long.  Then if a user wants to use spirit they can include what 
they need.
> 
> 
> 
>  >Formal grammar parsing should be user for formal grammar parsing. 
You
>  >fould very cool parsing framework that allow to substitute 20 line
>  >parsing function with one-liner, for the price of 600k of 
includes,
>  >lerning EBNF, compilation-time and probably portability. Would 
you rush
>  >using it? I rather not.
> 
> 
> 
> I think you are overestimating the cost here.  First of all, you do 
NOT 
> need to include everything (only ~400K in 1.2.5, not 600k).  The 
~600k (v1.3). That is includeing all non standart headers ( tuples 
and so on)

> spirit.hpp header is there for convenience only.  If you care about 
> compile time, you should only include what you are going to use.  
For 
> simple parsers, this is about 1/3 of the code, and compilation time 
is 
> not any worse than if you include, say <iostream>.

Really? what is the size of iostream headers you using?

> 
> Learning EBNF is trivial, and I think most programmers already are 
> familiar with it or are familiar with it's concepts (regular 
expression 
> syntax).

Are you so sure? I do not think so. More over I think that 
maintanance programmer that will encounter need to enhance/change CLA
parsing would choose to implement something in 2 hours instead of 
spending at least 2 weaks learning Spirit/EBNF. The tool sould be 
simple and obvios enough to encourage to use it even unfamiliar user 
(this is not a general rule, this is applicable just to bacis 
facilities).

> 
> Portability should not be a problem.  See above.  An older version 
of 
> Spirit has been ported to MSVC, and it should be possible for the 
new 
> stuff, once someone invests the time to actually do it.
> 
> --Dan Nuffer

Gennadiy.