"Vladimir Prus" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
