From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-05-29 01:00:11
Misha Bergal wrote:
>> You've missed the word "directly". You can't have all possible styles
>> work out of the box, because the number of possible styles is infitite.
> The problem with approach taken by the library is that to support the new
> style the user is advised to write a custom parser, although the author of
> the library uses different technique - it is not fair :-). If I was a user
> of PO library, I would be really confused, because cmdline class is closed
> to addition for me.
It's probably not that unfair --- the user is not expected to reimplement
all those style with custom parser. The idea is that most common styles are
packed in cmdline class and custom parser is for exceptional special
syntaxes. It would be possible to pack all styles supported by 'cmdline' as
separate 'style parsers'.
But the interaction between that will not be trivial. The parser for short
options "-k" must know that "--" starts a long option and don't process it.
It also much handle sticky short options. And so on.
In fact, I had the same kind of questions when looking at Gennadiy's code:
the policies did not look orthogonal to me.
> <speculative arrogant comment>I suppose that if all styles were
> implemented as separate parsers, some common parts would be refactored
> into something resembling Gennadiy's cmdline? and parsers themselves being
> a lookup policies?</speculative arrogant comment>
I'm not sure. I still don't understand many things about his code...
>> E.g. profile build of a simple program which uses
>> >> BGL takes several minutes for me. Yes, program_options is not as
>> >> large,
>> > but
>> >> what if you add 20 small libraries..
> It depends what I add them to. If it is one compilation unit as with your
> library - no problem, if it is 1000 compilation units as with std::string
> - big problem.
First, you might have several programs, all of which use program options.
Second, you might declare module-specific options in a translation unit
specific to module. So, it's probably more that one translation unit.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk