From: Dan Nuffer (dnuffer_at_[hidden])
Date: 2002-01-17 14:33:13
>>>* I was not able to find out portability report for Spirit. Since
>>>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
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 could be wrong, but Spirit seems to be static compile-time
>>>facility. I.e. I can't load CLA scheme dynamicaly or read it from
>>>configuration file. Also how would it distributed definitions?
>>Spirit is not static. Dynamic grammars are possible.
>Could you load rule from external file?
Yes, that's been done. Carsten Stoll and Zaph Lars are currently
working on generalizing their work to create a complete dynamic parser
(optional feature, of course) which will also allow users to specify
their own rule grammar.
>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
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
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>.
Learning EBNF is trivial, and I think most programmers already are
familiar with it or are familiar with it's concepts (regular expression
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk