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. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net