From: Arash Partow (arash_at_[hidden])
Date: 2008-03-28 09:04:35
John Femiani wrote:
> This is why I would like to see concepts spelled out like this:
> as is done by other boost libraries which I like, such as gil
> http://stlab.adobe.com/gil/html/index.html, BGL
> http://www.boost.org/libs/graph/doc/graph_concepts.html , fusion, and
> others. They all clearly specify their concepts using the SGI style and
> provide concept checking classes. To me that makes them easy to
> IMHO the core need from a point library is the concepts, not the models,
> because there are so many different well-tuned geometry libraries that
> exist, and the idea is that boost _algorithms_ work on any "point",
> rather than that boost have a great point class (those are easy).
The questions here is should the concept(s) spell out each and every
property of the object (point for example)? In the on going example
of the distance routine, say I provide a point that is comprised of
my_rational type. but I have not defined a sqrt function for it, should
say stuff like that be definable as concept as well - if so where do we
> Also, I already disagree about the idea that a point should have
> CoordinatesConcept should be part of a separate concept. Of
> course a useful point class will model both the coordinates and the
> point concept. To me a point should really support transform, scale,
> rotate, shear, and distance operations as free functions (maybe more).
> I don't know how to handle the idea of a 'space' or a 'kernel'.
Well they occur(are needed) when you want to re/define various operators
or truths. It would be go to somehow link type,object,routine and space
together - with obvious/common defaults provided by the library.
Be one who knows what they don't know,
Instead of being one who knows not what they don't know,
Thinking they know everything about all things.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk