From: John Femiani (JOHN.FEMIANI_at_[hidden])
Date: 2008-05-10 01:32:55
> Luke wrote:
> >> 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
> 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 :)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk