You do raise a valid point, there is currently no concept checking included in the design and implementation I checked into
Luke wrote: the sandbox.
Is it valid to call something a concept if there is no concept checking?
Bruno wrote:
Yes it is.
Oh, maybe my point of view was too narrow then :) In _this_ context I thought checking was a requirement, otherwise why make a class? without checking it is just documentation right?
But in my opinion, showing up a concept class has the advantage of clearly communicating the intention to the community in order to validate / invalidate the design. Moreover, since two geometry-related libraries are currently being developed for Boost (even if they don't do the same things) I think comparing the concepts used would allow us to see exactly what are the convergences / divergences, and see what can or cannot be done to make them as close as possible. A certain level of consistency between those libraries would surely be appreciated.
So what I am interested in is making those assumptions explicit, and providing the tools to check that my _own_ private code is going to work with whatever makes it into boost. That is why I say I care more about concepts (meaning checkable concepts & archetypes) than I do about the algorithms in a boost geometry library.
It actually forwards everything to the point_traits class in order to check that everything needed is accessible through point traits for the point type begin checked. Since you rely on point traits too, I suppose you would have the same approach?
My _personal_ opinion is that I prefer type generators or metafunctions to monolithic traits classes. When I looked at the CGAL kernel types (although it's been a while since I did) I realized how many typedefs etc. can pile up in a traits class. Frankly I think that makes traits harder to understand or work with. In the case of CGAL I did not know what a lot of the stuff meant because it dealt with aspects of geometry I was not dealing with at the time. Since I think any boost geometry library should be CGAL compatible, I would vote that the boost approach should be to decompose point traits into a bunch of metafunctions in their own tiny header files. You only include the header files with metafunction that apply to your task. For my two cents I reccomend: 1. Prefer metafunctions in the point concepts requirements over traits classes, or I'm afraid the traits will get huge. 2. Put your concept mapping functions in a namespace rather than a class (do it like like Fusion does). Namespaces seem to provide a lot more flexibility, and the syntax is a LOT cleaner. 3. Provide separate headers for each metafunction. This allows users to fucus on metafunctions that matter. 4. Make all requirements explicit in the concept class. This way I can look at the concept code and see what they are.
If you don't want to do that right now because you're afraid about the profusion of concept checking macros in your code, I think that putting a BOOST_CONCEPT_ASSERT in the point_traits class is sufficient with this approach, since any access to a point should be performed only through this class. This way, you don't have to rewrite the check in every algorithm, and the only job you have to do is writing the concept class. However, as I'm not used yet with the BCCL, I can be wrong...?
But what if somebody specializes your traits class? Then don't you lose the concept checks? I think explicit is better, so I prefer to place the concept check at the top of the algorithm that needs it. Better yet, apparently now BCCL has a BOOST_CONCEPT_REQUIRES macro (I havent used it). A concept check is a kind of documentation as well :) -- John