Luke wrote: Is it valid to call something a concept if there is no concept checking?
Bruno wrote: Yes it is.
John wrote:
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?
Um, not in my case. I am sort of stretching the concept class to serve additional roles, for instance, making it also the scope within which functions related to that concept are defined. When the free function of the library is called on a user type the related concept is looked up by metafunction and redirects the call to the function defined within that concept class. Also, I'm making no requirements on the user type except that it provide a default constructor and have an associated specialization of the traits class to provide accessor functions. I can check these requirements with concept checks on each function in the concept class, of course. John wrote:
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.
If your own point type has a default constructor and API sufficient to get and set the x and y values in any way you like it will work with my library. You would simply specialize the point_traits for your type and provide a typedef for your coordinate_type and two functions, one to get a coordinate and one to set a coordinate. John wrote:
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.
If the traits are huge the abstraction is being made in the wrong place. A good abstraction is a min-cut in a graph of dependencies. A huge number of metafunctions seems equally bad to me. Instead the goal should be to minimize the number of traits/metafunctions required to be understood/specialize by the user. That said I was already leaning in the direction of making the coordinate_type typedef a meta-function and moving it out of the traits.
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.
I am considering the implications of your suggestion. It could be that it can be made to work, but I'm not clear on how overloading functions in a namespace is preferable to specializing a struct. It seems that it is more prone to compiler errors related to overloading ambiguity caused by bad user code and unfortunate combinations of user code. With the traits there is no chance for ambiguity.
3. Provide separate headers for each metafunction. This allows users to fucus on metafunctions that matter.
I am doing this already, though there is only one metafunction that matters right now; the one that maps the user type to its related concept.
4. Make all requirements explicit in the concept class. This way I can look at the concept code and see what they are.
It isn't really my intention for the user to look at the concept code. I don't need the user to fully model the concept such that all functions can be called on it. If the user only uses the read only functions that don't modify or construct their data type they can partially model the concept if the have to. (Some programming styles require dynamic allocation of objects and prohibit default construction, in other cases the user may never want the library to modify an object of a given type.) Thanks, Luke