|
Boost : |
From: John Femiani (JOHN.FEMIANI_at_[hidden])
Date: 2007-10-07 19:33:48
[snip]
> > When I write code using points, I actually seldom have to use
directly
> > those accessors. I am not talking about writing the point class, but
> using
> > it. How often do we have to use something else than
functions/operators
> > (norm, +/-/*, etc.) on points in complex expressions?
>
> The thing is, you can never have a one-size-fits-all point type.
> Some folks say they need heterogeneous dimension types. If you
> use arrays, then you can't have those. And how about legacy types,
> need for higher dimensions, Etc.
>
> So, again, use concepts! And use them all the way! Don't generalize
> on concrete point types like above! You can't. Use concepts. An
elegant
> concept hierarchy for points should satisfy all the needs for all
> users. And, there can be interoperability between different models
> of the unified point concept.
>
> Regards,
> --
> Joel de Guzman
I would add that these concepts should NOT require coordinates for
PointConcept or SpatialVectorConcept, there should be a separate
CoordinatesConcept and RuntimeIndexedCoordinatesConcept (names may be
changed :) ).
I suspect most of this dialog would fall under what I just called the
CoordinatesConcept and RuntimeIndexedCoordinatesConcept. For instance
one can not add, multiply, or take the norm/length of points (you need
spatial vectors for that). You can also measure distance between
points, but not vectors. You can translate a point, but not a vector,
and you can not scale a point but you can scale a vector. Since
coordinates are free from interpretation you can do whatever you want to
with them, but the result is coordinates, not a point or a vector.
I think the concepts for a point would require a typedef for the vector
type, and likewise a vector would require a typedef for the
corresponding point type. Coordinates should probably satisfy both
concepts for a point and for a vector.
Again I do not know if these concepts or equivalents are part of GTL. Is
it appropriate/possible to try to flesh out details like this on the
boost wiki? Would folks be interested in starting up or helping with a
googlecode project to flesh out these concepts for a possible boost
submission at a later date?
-- John
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk