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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-05-27 23:36:25

Chuck Messenger wrote:

> Vladimir Prus wrote:
>> Chuck Messenger wrote:
>> 
>> 
>>>Vladimir Prus wrote:
>>>
>>>
>>>>Yep. This question was raised already. I think that making templates out
>>>>of all classes is *a* solution, but I'm not sure it's *the* solution.
>>>>The problem is that extensive template usage would prevent making
>>>>library --- either shared or static. I think that would be a big
>>>>downside.
>>>
>>>Why does that matter?  The great majority of other Boost libraries are
>>>header-file-only.  I think of .cpp components of Boost libraries as a
>>>sometimes-necessary evil, not as a desired feature.
>> 
>> 
>> Becase header-file-only libraries have two problems --- they increase
>> compilation times and they increase binary size. And you can't share the
>> code between different applications.
>> 
>> I think that's important practical aspect. In past, I was burned by
>> overgeneralization --- almost all core classes in a program had template
>> parameter. It had only one possible value, but I though different ones
>> were possible. As the result, compilation time was terrible, and no new
>> possible values for the template parameter became needed.
>> 
>> And these days, I'm rather unhappy with compilation times of BGL...
>> 
> 
> Perhaps you can do both: write the library with templates for a
> generalized string.  Then, supply "fast.cpp" and "fast.hpp" (choose
> better names).  Use a pimpl idiom in fast.hpp, so it doesn't need to
> include any template code.   fast.cpp includes the templates, but needs
> to be compiled only once.

That's a possible approach. But there are also at least two other:
- using preprocessor to generate two version
- using wstring internally with conversion on interface boundaries

I think it's better to wait for Unicode users to formulate what's needed. It
seems, for example, that the last approach would work better for me on
Linux.

- Volodya