$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: John Femiani (JOHN.FEMIANI_at_[hidden])
Date: 2007-10-05 14:46:02
 
> On 10/5/07, John Femiani <JOHN.FEMIANI_at_[hidden]> wrote:
> > If we want boost to have a point class I think it will really have
to be
> > a set of point adapters and point concepts that work for existing
types.
> > There are too many points out there that we would have to interact
with,
> > both outside of boost and also within boost.  For instance it would
be
> > nice if algorithms worked with both Boost.Point and the CGAL point.
> 
> I suggested something similar to this during a review (either Andy
> Little's Quan, or Boost.Units, I can't remember).  For example, a
> Boost dot_product could be implemented as such:
> 
> // Note: *SomethingDeducedHere* would be some BOOST_TYPEOF magic
> template <typename LHS, typename RHS>
> *SomethingDeducedHere* dot_product(const LHS &lhs, const RHS &rhs)
> {
>    return get<0>(lhs) * get<0>(rhs) + get<1>(lhs) * get<1>(rhs) +
> get<2>(lhs) * get<2>(rhs);
> }
> 
> Basically, just assume the point type acts like a tuple or Fusion
> sequence.  Then all the algorithms written can be used with any point
> class (with a little work in some cases).
> 
> --Michael Fawcett
Sounds great to me. Can or should we formalize this into a set of
concepts specific to points?  Coordinate access is only a part of what a
point rewuires; There is the tricky relationship between points and
vectors (not std::vector!)  and homogenous coordinates.  
I.e.  point+point is undefined, point-point is a vector, etc...
Also if there is a boost library (small or not) called point, I think
awareness of it would benefit developers.   Even if it did amount to
little more than a fusion sequence (sorry I don't know fusion --  I plan
to learn though :) )
-- John