John, First, let me thank you for taking a look at the code in the sandbox. I have made great strides so far with the community's help. Your input is greatly appreciated. John wrote:
I am still a bit unsure about the 'concept' word that is being thrown around. ... The reason I mention this is that the point_concept.h file has >no constraints, so it cant be used with BCCL, as far as I know.
I dont know if I have a narrow opinion here, but this is what I am interested in even more than algorithms or actual models of 'PointConcept' or whatever.
I think your interest is the same as that of the rest of the boost community. Whatever the library does, it has to do it the right way to be considered for acceptance into boost. I'm not entirely sure I understand what you mean by point_concept.h has no constraints on the point data type. It references a point_traits<T>::coordinate_type. Any data type that does not provide a typedef to coordinate_type, or specialize point_traits<> with a typedef for coordinate_type will not be allowed to compile with the point concept. Similarly there are the point_traits<T>::get() and set() functions, which must either work with the given data type, or be specialized to work with the given data type. Are these not constraints on T? I suppose I could have named point_traits as point_concept_map instead to be a little more explicit about it. Would that name change make things more clear? I am restricting myself from making explicit requirements of the user data type (except that it have a default constructor) and instead use the concept mapping traits struct for all interaction with the data type. In this way, all data types defined before the library was written and can still be adapted to work with it without being modified to conform to its expectations. You do raise a valid point, there is currently no concept checking included in the design and implementation I checked into the sandbox. Is it valid to call something a concept if there is no concept checking? I think so, but I could be taking too broad a view. Once the design is finalized and implementation is mostly completed I was planning on adding some concept checking, but in fact, the only benefit of such checking is earlier and less verbose compiler errors when incorrectly using a template. This is of little benefit to me while authoring the library, and only marginally beneficial to the library user. The error they will get if they fail to specialize the traits for their legacy point type is that their point doesn't provide a get() function, which they can fix by providing one. I was also planning on translating the library to use the new c++0x language features once available, so it is my intention to use concepts, even if I'm not now technically doing so if that implies compile time concept checking when taking a narrow view of concepts. Thanks again, Luke