Re: [boost] Preview 2 of a template Geometry Library

From: John Femiani (JOHN.FEMIANI_at_[hidden])
Date: 2008-03-27 06:52:06

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