Boost logo

Boost :

From: rogeeff (rogeeff_at_[hidden])
Date: 2002-01-18 16:03:27

--- In boost_at_y..., "David B. Held" <dheld_at_c...> wrote:
> -----Original Message-----
> From: rogeeff <rogeeff_at_m...>
> To: boost_at_y... <boost_at_y...>
> Date: Friday, January 18, 2002 12:43 PM
> Subject: [boost] Re: Any interest for a parser class?
> >Generic parser should not rely on ANY parser. It should
> >not even need not know about existance such beast like
> >complex parser.
> I think I understand what you are suggesting now. You are saying
> that a CLA library should not be responsible for actually *parsing*
> the options, just storing them. I don't see a general concensus on
> this view. Even Bill Kempf's implementation parses the input
> "internally". I assume Vladimir Prus' implementation does so as
> well.

No CLA framework is responsable for parsing. In simple cases it uses
internal means. In non trivial cases provided by user.

> >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.
> If I understand you correctly, you are saying that the CLA library
> would provide a minimal set of parsing structures to handle most
> common situations, but they would be external to the CLA
> framework itself. To me, that seems odd.

No, they are essential part of the framework.

> >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.
> So for someone to imlement custom option formats, they have
> to provide their own parser. Sure, that's very flexible; but how
> powerful is it?

We will see.

> I wouldn't be highly motivated to use such a 'lazy'
> CLA library myself.
> And ultimately, you are suggesting that the CLA library ship
> with several hand-rolled parsers.

To parse -option, --option, /option= the framework would not need
complex parsing facilities.

> Well, as long as that remains
> a fixed set, that's fine. But as people have need for more
> complex option formats, the value of a non-parsing CLA
> library will decrease significantly. Whereas, the set of
> included parsers themselves could have been the products of
> a parser-generator; in which case you already have an engine
> for creating new parsers for new formats.
> We went from std::auto_ptr to boost::smart_ptr.

No, we did not. One safisfied with auto_ptr would not use smart_ptr.
It's to expensive sometimes.

> Now we're
> talking about Loki::SmartPtr because we aren't satisfied just
> handling the minimal set of cases. Isn't it taking a step back
> to offer such a weak CLA library? I mean, you said yourself
> that hand-rolled CLA parsers are a dime a dozen, and now
> you just want to standardize one. It seems to me that boost
> is not about libraries that just anyone can write. It's about
> powerful libraries designed carefully and thoughtfully by
> fairly intelligent people, that the rest of us have the benefit of
> using. Since a more powerful parsing engine is already
> available to us, why not create a more powerful CLA framework

Cause it not obvios that "power" is a major prioriry for CLA
framework. Flexibility - yes. No need to mix this things.

> that *can't* necessarily be hand-rolled in 2 hours, that
> covers a much broader range of possibilities, in the way
> that smart_ptr covers more possibilities than auto_ptr?
> I know someone that swears by auto_ptr, and never even
> considered using boost::smart_ptr, insisting that it's
> unnecessary for most situations, and so there's no point
> in using it or learning a "more complicated smart pointer".
> On the other hand, I don't know anyone who's actually used
> boost::smart_ptr and failed to recognize the value it adds
> to their code, even though they may have had to read a
> little more documentation to use it properly. I can't help but
> feel that you are that person saying: "I really like std::auto_ptr.
> It's good enough for me, so it's good enough for everyone."

No I am saying: I really like to use std::auto_ptr sometimes.
when it's good enough for me, so please do not forse me to use
smart_ptr always.

> Dave


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