Re: Any interest for a parser class?

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

Gennadiy.