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
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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk