From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2008-03-06 12:24:45
On Thu, Mar 6, 2008 at 5:34 AM, Bruno Lalande <bruno.lalande_at_[hidden]> 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
Yep, x, y ,z were just examples. See my posts here
http://thread.gmane.org/gmane.comp.lib.boost.devel/165828 and here
concerning tuple use. I have sample code locally that shows run-time
array indexing combined with tuple-like compile-time access.
myvec = 1;
boost.get<0>(myvec) = 1;
There's also sample code here
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
I see good use for:
IndexablePointConcept - supports runtime indexing (array-like access,
TupleAccessConcept - supports boost::get<N>(vec) syntax
at a minimum, and we can probably think of more.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk