[boost] Re: CLA/Config file library opinion

From: Misha Bergal (mbergal_at_[hidden])
Date: 2003-05-28 05:54:11

"Vladimir Prus" <ghost_at_[hidden]> wrote in message
news:bavhr2$dsj$1_at_main.gmane.org...
> Gennadiy Rozental wrote:
[snip]
> >> > 2. Layered design.
> >> > This has many
> >> > problems:
> >> >    a. Limit number of supported styles die to bitmap limitation
> >>
> >> The number of directly supported styles will always be limited. For all
> >> others, users will be compelled to write they code --be it a function,
> >> or a policy.
> >
> > It's only limited in your design.
>
> 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.

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

[snip]
> >> If a library can be implemented externally, it should. Linking to a
> > library
> >> is minor problem
I don't think so.

>. Inlining/templating will only
> >> - add compilation time.
I don't think so.

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