From: Misha Bergal (mbergal_at_[hidden])
Date: 2003-05-28 13:55:29
"Vladimir Prus" <ghost_at_[hidden]> wrote in message
> 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.
Some ways of preprocessor use might be problematic for the same reason as
library distribution .
In case of preprocessor - it is another define to add.
In case of (shared library) - it is another lib to add.
Both increase user's costs.
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
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
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.
Total: Signals - 2, Regex - 1, PO - 0. That's great news for PO library and
its users :-).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk