Re: [boost] Is there any interest in a template geometry library?

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2008-01-15 17:08:30

Barend Gehrels wrote:
> Is there any interest in a template geometry library?

There certainly is.  My particular interest is in efficient containers 
for points (and perhaps lines) with iterators over 2D ranges; have you 
done anything like that?

Some random thoughts:

Of course you're aware of the GTL proposal from a group at Intel last 
year.  Here is my recollection of a couple of aspects of that discussion:

- It turned out that their implementation uses a cast from a base class 
to a derived class, which works because the derived class has the same 
layout as the base class in all known compilers.  This is a pragmatic 
choice, but it's not the sort of thing that's going to be popular with 
Boost people as the list discussions revealed.  Unfortunately, because 
their library is complete and in use, they're too far down the road to 
change something as fundamental as that.  When I read "We at Geodan are 
developing our library since 1995", I was immediately worried that your 
library would also turn out to have some unpopular feature at its core, 
now impossible to change.  So letting us see the code ASAP is 
definitely a good idea.

- A feature of GTL is that it can accommodate arbitrary point types by 
means of suitable adapters.  I had mixed feelings about this.  On one 
hand, this makes it possible to apply their algorithms to legacy data 
structures.  On the other hand, I think that it would add an extra 
layer of complexity for new users who have no legacy to worry about 
(and library learning-curve steepness is something that I give a lot of 
weight to).  Compare this to the standard library: using maps I often 
find myself writing "first" and "second" when I'd prefer to be writing 
"key" and "value" or "customer_number" and "address".  If std::map 
could be adapted to work with arbitrary structs, rather than std::pair, 
that would be a good thing.  So maybe we do need this extra layer.  
Except that it might make coding the libraries more complex, and my 
space-filling-curve point-set was at the limits of my C++ ability 
already!  Indecision.

Considering GTL, this library, GIL, and even CGAL, how much commonality 
is there?  Are there shared concepts between all of these libraries?  
Can we extract some common concepts or patterns from the different libraries?

Perhaps something that's also worth asking is whether Boost is the 
right place for such a library.  Getting releases out has not been a 
smooth process over the last couple of years, and I can't imagine that 
adding more libraries makes it any easier.  Maybe Boost ought to focus 
more on things that are close to the standard library, and let other 
code find a home elsewhere.

Regards,  Phil.