
Boost : 
From: Max Motovilov (max_at_[hidden])
Date: 20080325 23:57:08
A few more notes after looking through the documentation at length:
 I agree that it makes sense to make Point a concept. But it looks like
other geometries need it even more. For example, geometry::polygon<>
encapsulates a fairly complicated data structure but adds little
functionality on top of it; linestring and linear_ring provide even
less. On the other hand, I imagine the algorithms don't need full
container functionality from the geometries in most cases and could get
by with a sequence (pair of iterators). Perhaps formulating concepts
around those entities would help generalize the algorithms even further.
I realize that at this point I should be suggesting an alternative
design :) but to do that I'll have to look at the algorithm
implementations first, not just the interfaces... and I'll try to get to
it later. My own generic algorithms usually dealt with sequences
alone, STLstyle but I've never parameterized them as extensively as you
do it.
 Arithmetics with points and vectors (operator overloading and simple
functions): it is mostly syntactic sugar, but it tends to make code
shorter and more readable. I'm sure you have some, maybe a lot of it,
but the docs are a bit hard to navigate in that respect.
 Another 2 types of geometries I found useful in certain algorithms
(e.g. computing straight skeletons or line widening) are infinite lines
and rays, along with segments that you already have. The key operations
for them are of course intersections.
 Point to linestring distance algorithm should be able to provide the
information (iterator?) as to which segment (or vertex) of the line
turned out to be the closest.
 Something I was thinking about but has never done yet... which of the
geometrical algorithms could be effectively implemented on sequences of
polynomial curve segments (quadratic and cubic Beziers are my natural
favorites)? If feasible, this would be a very powerful tool for 2D graphics.
More to come.
...Max...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk