[boost] Re: Re: Formal Review: Command Line & Config library

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-05-29 01:52:39

Hi Misha,

Misha Bergal wrote:

> "Vladimir Prus" <ghost_at_[hidden]> wrote in message
> news:bb1e2t$gc7$1_at_main.gmane.org...
>>
>> I think the point is that you hardly want both ascii and unicode in
>> single program. In that case two versions of shared library can be built:
>> for ascii and unicode, and you will link to the desired one. It's
>> actually not necessary to add templates --- probably preprocessor will
>> do.

> If user doesn't have a good build system or is not educated enough to use
> one - she will have to struggle a little bit (may be quite a bit). How
> will he specify the Unicode or non-Unicode version of the library to link
> with - project settings?, windows library autoselect (the whole thing with
> program_options_udd, program_options_dd, program_options_ds,
> program_options_uds etc.). Those issues are not specific to this library
> and are not unresolvable, but comparing it with other 2 libraries (in
> distribution sense) - regex and signal.
> 
> Program options will probably be used in just one place, as compared with
> regex and signals which can be used in many places.
> Regex and signals get one point for going to the library

I can expect program_options to be used in several places --- for declaring
options. Also, if regex and signals were implemented inline, duplicate
template instances/inlined functions will be removed during linking, so the
argument applies only to compilation speed. Ok, so regex/signals get half a
point.

> Program options would have 2 possible template arguments char and wchar_t,
> regex - 2, but signals much more than that.
> Signals gets one point for going to the library

The code in library is not template. If it were declared as inline, there
still would be one copy for all possible template parameters. No points to
signals, IMO.

> Instantiated program options code takes much more space than regex and
> signals one. Even if that is true - it is in just one/two compilation
> units where the compilation time and their binary sizes would be affected.
> It is still going to affect the size of the application the same way (I
> don't think I would want to use program options as a shared library).
> Program options gets no point here.

There's one important aspect. You're no likely to use signals just to try it
out. You either use it through all your application or not use. Signals
migh have serious impact on the way you structure code and give you serous
benefits. 

Parsing of command line is not such an important thing in the whole program.
So, the compilation time/space overhead must be small. 

This is at least 0.5 points to program_options

> Total: Signals - 2, Regex - 1, PO - 0. That's great news for PO library 
> and its users :-).

In my opinion, we get 0.5, 0.5, 0.5 ;-)

- Volodya