Boost logo

Boost :

From: Joel de Guzman (joel_at_[hidden])
Date: 2006-10-17 22:14:59

Ullrich Koethe wrote:
> Joel de Guzman wrote:
>> Lubomir Bourdev wrote:
>>> This is why in GIL we allow the type of the result to be specified
>>> explicitly upon invoking the operation. Promotion traits can at best be
>>> useful for a reasonable default, but even then we feel that they belong
>>> in boost::type_traits and not in an image library, as the problem
>>> generalizes beyond images.
>> I agree. I am not quite fond of monolithic libraries that do everything.
>> Promotion traits and clamping, for example, can also be useful for, say,
>> signal processing of audio, among other things.
> True. But on the other hand, one has to control the number of external
> dependencies -- if a potential user must install 5 or 10 other libraries
> first, he might quickly loose interest.
> In image processing, one wants at least libjpeg, libtiff, libpng (which in
> turn requires zlib), perhaps a fourier transform library, possibly boost,
> a linear algebra library (for warping and curve fitting), a GUI library
> (which often already comes with incompatible image import/export
> functionality) and so on -- there is certainly a trade-off between
> internal and external solutions. Of course, there are platforms where
> installation is easy, but you want to be general.

Isn't this a problem of packaging instead of monolithic vs. modular
libraries? IMO, the level of granularity of a library reflects its
design. A well factored library, as a result of extensive refactoring,
over time, results in small highly orthogonal, loosely coupled sub-
libraries. A monolithic library, on the other hand, tend to devolve
into chaos over time. Don't get me wrong. I am not referring to
VIGRA; I am not familiar with it and its design. I am just talking
in general terms. And, referring back to GIL, I see that it hits the
exact sweet spot in terms of modularity.


Joel de Guzman

Boost list run by bdawes at, gregod at, cpdaniel at, john at