Re: [boost] Generic Point class and algorithms (was: [GTL] - geometric template library - determininginterest)

From: Joel de Guzman (joel_at_[hidden])
Date: 2007-10-05 19:47:22

Michael Fawcett wrote:
> 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).

In my world, structs are tuples and tuples are structs. Duality.
The minimum interface, if you guys do not want to fuss around with
fusion, is this:

1) a metafunction to get the size of the tuple (dimensions for points).
2) a metafunction to get the element type given an index.
3) a get/at_c function that returns the actual data.

That's all. I can provide a non-intrusive adapter for that for Fusion
easily for those who want to do more aggressive generic programming
on these specialized tuples. Your interface itself need not have
any hard dependency on fusion.

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net