I am extremely interested in a boost affine geometry library, but given the history on this mailing list I suspect the best approach might be to start with less rather than more. I don't know if this works with boost libraries but I think I would like it if a minimal point/vector/coordinates library, which basically just provided concepts and models for proof of concept, was accepted and additional algorithms on top of them came later.
-- John C. Femiani
This has been well discussed many times: make Point a concept and allow many models of the Point concept. It is a mistake to have a single do-it-all point class. What if I want a 2 dimensional point with a short for x and a long for y? Your class can never satisfy all possibilities. The best strategy is to allow for multiple point models be usable in your algorithms cout << distance(p1, p2) << endl; cout << distance(p2, p3) << endl; Joel de Guzman This is how it is implemented. More points are possible, two points are
Thanks for all answers and comments on my preview. I knew that the subject is difficult and lends itself to many discussions. I will not answer all mails individually so I paste some snippets to cover most things. First about the vector/matrix calculations. They are intentionally left out the library, because it is a separate thing. You can do geometry without (much) vector/matrix calculations and you can use vector/matrix without doing geometry. Besides that it is already in Boost: uBLAS contains vector/matrix calculations. So I decided to not do it again. To make this more clear I reworked a sample and added it to the preview: http://geometrylibrary.geodan.nl/examples.html, see 6 transformation example. Besides transformations, there are small vector calculations necessary inside any geometry library. They are now coded inside but another library could be used. This is also explained on the example-page. Then about the point class: provided, strategies can be defined for any point type. The distance calculation can be done exactly as stated above. About the "point concept". I've looked at the concepts, downloaded and tried the concept compiler. However, in this geometry library there are more concepts possible. As long as you attach the right strategies with the points, you can use any point, at least, that is the intention. I provided a basic point with an array and neutral names as "value", but even that is not really necessary. In the documentation I added notes about the concepts and requirements, with some classes, but not yet with all of them. About the point_xyz: I intentionally left that out to not give the intention that the library is a 3D library. 3D could be added but at this moment it is not. Algorithms are for 2D points, and after the first preview I added the latlong points as well (but I didn't implement all strategies for them). Finally about the compiletime area calculation: sorry that I've mentioned that, it was really a small experiment. Because there is interest I will relook at it, but it should not distract the list from the focus: the preview, without vector/matrix calculations, with affine geometry and latlong geometry, and if that might be a starting point for a boost geometry library candidate. Best regards, Barend Barend Gehrels, Geodan, Amsterdam.