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.