John Femiani wrote:
This is why I would like to see concepts spelled out like this: http://www.boost.org/libs/concept_check/reference.htm#basic-concepts 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 understand.
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 stop?
Also, I already disagree about the idea that a point should have coordinates.
I agree
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. Arash Partow __________________________________________________ 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. http://www.partow.net