RE: [boost] Re: Any interest for a parser class?

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-01-18 08:55:05

> From:	rogeeff [SMTP:rogeeff_at_[hidden]]
> 
> > From: "joel de guzman" :
> > 
> > > So the numbers don't lie. In terms of code size,
> > > Spirit outperforms Gennadiy's code hand written code.
> > > 146K vs 180K in this trivial example.
> > 
> > BTW. I preprocessed both files and the Spirit version is 1MB (v1.3)
> > and 843K (v1.2) [ this includes the standard libs ]
> > 
> > *** This should drop considerably when spirit-core is isolated ***
> > 
> > while the hand-coded tokenizer version is 793K 
> > [ also includes the standard libs ]
> 
> I am not sure that it is reasonable to compare generic parser 
> implementation with Spirit one, since first one would not affect user 
> code, while second one does. Custom parsing rules that introduced by 

This is simply not true. If the CLA interface exposes Spirit, then those
portions of Spirit necessary for that exposure impact user code. If a CLA
user doesn't use that Spirit functionality, then the overhead is only that
which must be exposed. Joel (IIRC) already mentioned that there is a file,
spirit_fwd.hpp, that forward declares pieces. That is probably all that
would need to be exposed. You've pointed out that there is a dependency on
tuples in spirit_fwd.hpp, so there is, indeed, significant, though not
egregious, overhead with this approach.

OTOH, the CLA could abstract away all dependence on Spirit, as has been
suggested in other posts. Then, the overhead is completely under the control
of the CLA component. However, if the CLA is implemented using Spirit, then
any other parsing the programmer requires can use Spirit without any further
impact on executable size (other than the parser-related logic they write,
of course). Obviously, if a custom -- not Spirit-implemented -- CLA were to
depend upon other standard/Boost components, then the same argument holds;
this doesn't apply to Spirit alone.

> user are not part of the generic framework and as I assume will be 
> considerably rarely used, while Spirit overhead will be present 
> always. Depending what I prefer I could choose more safe, small, 
> quick or powerful solution and use appropriate tools to implement it.

If you assemble several custom parsers, such as a parser for CLAs, a
configuration file, a data file, HTTP, etc., into a single application, then
the overhead is significant. If all of those parsers were implemented using
Spirit -- or any other common parser generator, for that matter -- then the
binary would be smaller. Besides, maintenance of those components is vastly
simpler if they all use Spirit for implementation.

The CLA component can be designed in isolation. If it is based upon Spirit,
then maintenance of that component is simplified as compared to a
custom-coded solution. If the CLA interface exposes Spirit in some way, then
clients also have a dependency -- at least at compile time -- on Spirit. If
the CLA abstracts out its dependence on Spirit, then clients have no
dependency on Spirit. The choice is up to the designer(s)/developer(s) of
the CLA component; there is insufficient information at this time to make
that determination.

Since neither a CLA component nor Spirit have been accepted into Boost,
these discussions are purely academic. If a CLA is accepted into Boost
before Spirit, then it cannot be implemented using Spirit, but its interface
should, at least, not preclude it in the future. If Spirit is accepted into
Boost before a CLA component, then proposed CLA components will be
scrutinized for their use or failure to use Spirit.

Furthermore, since no CLA component has been accepted into Boost, the "best"
interface has yet to be decided. Perhaps your ideas for how to handle the
job will clash with others' needs/wants. Perhaps you'll find the final
requirements to be different from your current idea of them, possibly making
the facilities of Spirit all but necessary.

On a different note, you've complained about Spirit's portability. This is
always a concern, but portability of Boost is often a problem and requires
not insignificant effort to resolve. Perhaps your compilers are among those
not well supported. That doesn't mean Spirit is not portable. (I think you
mentioned using MSVC5. If so, you can hardly blame your compilation problems
on Spirit. MSVC6 is much better, even while widely missing the mark of
standard compliance.) Nevertheless, these portability issues can be
resolved, in the general case, so don't dwell on them too much.

Let me summarize by saying that you should not be so quick to argue against
what you don't know or understand. I'm not saying Spirit is the right
solution, but it sounds very promising, as a separate component and for the
implementation of a CLA component.

Rob
Susquehanna International Group, LLP
http://www.sig.com