Boost logo

Boost :

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.
> >>>CLA
> >>>parsing is very basic facility, I should be able to compile it
> >>>majority of compilers.
> >>This _is_ an issue with Spirit. The developers are working on
> >>IMHO braindead compilers should not direct the design of
> >>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
> compiler I know of that the current code does not work with is
> 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
> >is inherited by my users and is not implementation detail.
> No, you can include spirit_fwd.hpp in your header, which is < 100

~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.
> >fould very cool parsing framework that allow to substitute 20 line
> >parsing function with one-liner, for the price of 600k of
> >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
> 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.
> simple parsers, this is about 1/3 of the code, and compilation time
> 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
> 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

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at