Boost logo

Boost :

From: rogeeff (rogeeff_at_[hidden])
Date: 2002-01-18 13:35:34

--- In boost_at_y..., "Stewart, Robert" <stewart_at_s...> wrote:
> > From: rogeeff [SMTP:rogeeff_at_m...]
> >

> 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
> of course).

It depends. Since Spirit is implemented inline every module that uses
it will be affected.

> Obviously, if a custom -- not Spirit-implemented -- CLA were to
> depend upon other standard/Boost components, then the same argument
> this doesn't apply to Spirit alone.

Generic parser should not rely on ANY parser. It should not even need
not know about existance such beast like complex parser. It can
handle fixed range of argument iddentification/value parsing rules
(but wide enough to cover most of CLA parsing needs) and provide an
abstract interface for user to add custom argument. This argument
encapsulate and implement somehow custon parsing logic, that include
custom identification and custom value parse. That's it. And let
everybody decide whatever they want to use.

> > user are not part of the generic framework and as I assume will
> > 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
> 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.

See above.

> Besides, maintenance of those components is vastly
> simpler if they all use Spirit for implementation.

We can use Spirit in any place where we need to comvert string to
value and no need to know lexical_cast.


> Since neither a CLA component nor Spirit have been accepted into
> these discussions are purely academic.

CLA component is under development.

> If a CLA is accepted into Boost
> before Spirit, then it cannot be implemented using Spirit, but its
> should, at least, not preclude it in the future.

Sure. As I sad it sould need to know about any parser at all.

> 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.

From my standpoint they are not related to each other (again, other
then one can implement custom parsing using Spirit, ... or tokenizer,
regexp, lexical_cast scanf and so on).

> 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
> 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.

I was trying to compile v1.3 on MSVC6SP5 and latest Sun compiler(not

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

It sound misleading from generic CLA framework implementation

> Rob
> Susquehanna International Group, LLP


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