Re: [boost] Summer of Code 2008 Ideas

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
http://thread.gmane.org/gmane.comp.lib.boost.devel/165828 and here
http://article.gmane.org/gmane.comp.lib.boost.devel/144070/match=dot%5fproduct+get
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