On Thu, Mar 6, 2008 at 5:34 AM, Bruno Lalande <bruno.lalande@gmail.com> wrote:
Hopefully these can avoid the boost minefield relating to 'point' types because trees only work on coordinates (no need to intepret them as "points" per se), and meshes are entirely topological.
I don't see anything wrong with a CartesianCoordinateConcept that requires x(), y(), z() along with typedefs or something to that effect. I think the consensus that was reached with the "point" discussion is that too many people want too many different things out of a generic point class, but the algorithms are concerned with very few details of the point class, mainly just "expose x, y, and z, and the types of each" - so don't try to make the perfect generic point class, let people use their own. Just provide algorithms that will work with their point classes, as well as the default (very basic) point class provided by the library.
This is exactly what I think too. The lack is not about the structure (everybody has one and is happy with it) but the algebra applied to them (everybody reinvents the wheel on his own structure). Just one point: requiring named accessors (x(), y(), z()) would bind us to a specific number of dimensions. One very common need is to be dimension-agnostic. In terms of structure we already have that : Boost.Tuple. So the idea would be to have your CartesianCoordinateConcept requiring templated accessors get<0>(), get<1>(), etc... instead, this way the algorithms could work by default on tuples.
Yep, x, y ,z were just examples. See my posts here http://thread.gmane.org/gmane.comp.lib.boost.devel/165828 and here http://article.gmane.org/gmane.comp.lib.boost.devel/144070/match=dot%5fprodu... concerning tuple use. I have sample code locally that shows run-time array indexing combined with tuple-like compile-time access. e.g. myvec[0] = 1; boost.get<0>(myvec) = 1; There's also sample code here http://thread.gmane.org/gmane.comp.lib.boost.devel/165727/focus=165825 but it doesn't have the tuple access in it. I think Joel de Guzman mentioned some really good ideas in previous threads. He suggested IndexablePointConcept for algorithms that required runtime indexing, and not requiring it unless needed. So it's a much more fine-grained approach than just some blanket PointConcept. I see good use for: IndexablePointConcept - supports runtime indexing (array-like access, e.g. vec[0]) TupleAccessConcept - supports boost::get<N>(vec) syntax at a minimum, and we can probably think of more. --Michael Fawcett