|
Boost : |
From: Andy Little (andy_at_[hidden])
Date: 2006-10-06 10:01:36
"Stefan Seefeld" <seefeld_at_[hidden]> wrote in message
news:4526579E.6040003_at_sympatico.ca...
> Andy Little wrote:
>> "Lubomir Bourdev" <lbourdev_at_[hidden]> wrote in message
>
>>> Another problem is that a library cannot consist of just concepts. You
>>> need to have concrete models. GIL provides only the models it needs in
>>> practice - a 2D image comprised of pixels in a specific color space. So
>>> another reason we can't have a "Display Matrix" library is that we don't
>>> have existing models that go with it.
>>
>> Yes I think this is the heart of the problem! The library claims to be
>> generic
>> but is in fact tightly coupled to one domain.
>
> IMO 'generic' doesn't have to translate to 'domain-agnostic'. Generic here
> means that the individual models used are orthogonal, so it is easy to
> combine different representations of these models into working code.
> There is the 'Image' container, and there are various 'Pixel' types images
> are composed of. Generic means that both models are presented as concepts
> (and in fact I'm totally delighted to find the documentation use Concepts
> to present them !),
I wasnt going to bring it up, but I was specifically told not to use Concept
docs. OTOH maybe different rules apply depending on who you are I guess?
> making it easy to provide alternative Image and Pixel
> implementations.
> I'm working on a library for high-performance signal and image processing
> (http://www.codesourcery.com/vsiplplusplus) and I'm looking forward to
> trying out GIL's Pixel types with my own Matrix types. That's what 'generic'
> is all about !
Its looks very nice....
regards
Andy Little
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk