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.