|
Boost : |
From: Andy Little (andy_at_[hidden])
Date: 2006-10-11 02:29:32
- What is your evaluation of the design?
I believe that the various Concepts namely treating a data sequence as a view on
a matrix or grid, iterating a matrix or Grid , and Color have not been
adequately thought about in their own right.
I do like the locator concept, though AFAICS this has a lot of similarities to
an iterator over a 2D or 3D grid, but again these could Concepts (e.g step
iterator) could be abstracted out and then more generally useful
- What is your evaluation of the implementation?
I didnt look in detail. It appeared that some typedefs were only there to meet
GIL Concept requirements and appeared to be unused. This is an indication that
the implementation probably has unneccessary dependencies.
- What is your evaluation of the documentation?
Links to the Concepts don't work (they point to local files on my system). This
makes it tedious to wade through. It would be preferable to have local HTML
documentataion in full.
The use of ConceptC++ style concepts is problematic. My suggestion is that if
one wishes to use this style in the Docs then you should also follow through and
actually put the Concepts into code and compile them on ConceptGCC. You could
then verify that the documentation is correct. I suspect that the current GIL
docs would require a lot of work to pass that test. In fact I would make that a
requirement for any Docs that wish to use the ConceptGCC format.
This would be an interesting discipline and I suspect would result in design
changes to the library itself.
Overall the docs seems patchy. I would suggest looking at other boost docs and
seeing the difference in format. For one thing separating code tutorial and docs
into separate dwnloads is confusing and time wasting. Look at librraies in the
boost vault to see somethng of a common format.
- What is your evaluation of the potential usefulness of the library?
I see the usefulness in terms of separating the above Concepts. This would be
more useful as various separate libraries. Each of the above Concepts is complex
enough to deserve its own library.
- Did you try to use the library? With what compiler? Did you have
any problems?
There is a format (official or unofficial) for library reviews, which has not
been followed. The code is designed to be copied into the reviewers boost
distribution for evaluation. The installations section of the tutorial doesnt
cover quite what you are meant to do to install the library. The lack of
detailed information is a common theme. I get the impression I am meant to be an
expert in the domain to use the library. This put me off sufficiently not to
bother trying the code.
Suggestions for a first example. Load an image, provide some means or
suggestions so that you can view the image. Show code for a transform of the
image. View the result. Proceed like that. This would make for a much more
powerful and comprehensible tutorial and would certainly get me more interested.
- How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?
I found the documentation hard to follow for the reasons given above, hence I
didnt look in detail.
- Are you knowledgeable about the problem domain?
No. Overall this is the libraries problem . It is very domain specific and the
domain is specialised. Some of The Concepts ( actual rather than documented) are
interesting, but the library seems intended for experts in this particular
domain, not fro average users like myself.
I vote to reject GIL in its current state. I would suggest the most useful part
of the library potentially is that dealing with Colour, but not from an experts
point of view as currently implemented. I would suggest thinking about how to
make an easy to use Colour interface, maybe looking at current "standards" such
as VRML, SVG, HTML, MFC. These are written from a users rather than a hardware
viewpoint and all have similarities and AFAICS there is no insurmountable
problem to provide an interface for the general user in an image processing
library.
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