Boost logo

Boost :

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
> tuples.

Yep, x, y ,z were just examples. See my posts here and here
concerning tuple use. I have sample code locally that shows run-time
array indexing combined with tuple-like compile-time access.


myvec[0] = 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,
e.g. vec[0])
TupleAccessConcept - supports boost::get<N>(vec) syntax

at a minimum, and we can probably think of more.

--Michael Fawcett

Boost list run by bdawes at, gregod at, cpdaniel at, john at