Steve Robbins wrote:
CGAL is huge, in part, because it provides all the higher-level stuff like triangulations, meshing, surfaces, and the like. The focus here is much much smaller so I don't think anyone imagines it turning into CGAL.
Much of the discussion here surrounds defining a Point concept, which is valuable, but you typically also need related concepts Vector, Ray, Line, and Segment, together with the predicates (like point orientation) and constructions (like segment intersection). CGAL bundles all these together in a geometric traits class called a Kernel.
If all of these traits are all bundled together, then the CGAL Kernel concept really can't be very minimal, right? This means that algorithms written to this concept would require more than they should, which would them harder to use.
One of the attractive features of CGAL, to me, is that their algorithms are templated over the Kernel type. So you can use exact geometric computing if desired, or play fast and loose with doubles, or do something in between (exact predicates, but inexact constructions) just by choosing the appropriate Kernel.
I think the GTL submission used traits as well, but I prefer type generators and metafunctions like iterator_value<It>::type instead of std:iterator_traits<It>::value_type. That way you can provide or require only the traits that matter.
Superficially, the discussion here seems to be talking only about one tiny part of a geometry kernel, namely points and simple functions like distance. Is the end goal just that: a set of primitives with no regard to robustness?
Alternatively, if the ultimate goal is larger, then how does it differ from a CGAL kernel? If the CGAL kernel concept is too complicated, what is going to be omitted? Is there some part of a kernel that is unnecessary? Are there CGAL design mistakes (from its 12-year history) that can be done better?
For myself I want to know what interfaces to use in my code so that is more generic and easy to use. I want concepts to check with function_requires<> and I want archetypes to test that my code does not require more than is absolutely necessary. An algorithm written to the boost concepts should work on CGAL as well. In fact I propose interoperability with CGAL primitives should be a requirement for any boost geometry library. I think the answer to "what is going to be omitted" is that each algorithm should be able to omit some parts, the boost concepts & traits should be granular. Also, I think it is against the boost rules for a boost library to depend on CGAL. (Is that right?) -- John Femiani