-----Original Message----- From: miles.bader@necel.com [mailto:miles.bader@necel.com] Sent: Thursday, October 04, 2007 8:47 PM To: John Femiani Cc: boost@lists.boost.org Subject: Re: [GTL] - geometric template library - determininginterest
"John Femiani" <JOHN.FEMIANI@asu.edu> writes:
What is not lightweight about the get<0>(pt) syntax? Doesn't it compile away? Is the issue a dependency on another library -- because the get<0>(pt) syntax seems really easy to provide without bothering with Fusion.
template <int Index> float get(MyPoint & p) {return p[Index];} template <> float get<0>(MyPoint & p) {return p.x;}
How does this work with non-constant indices? That's a significant reason why array-style access is useful ...
-Miles
Array access has it own problems; I think we would need to accommodate both. I am not too familiar with fusion; but I have used GIL which has concepts for heterogeneous as well as homogeneous types. The most generic type of access is obtained by something like the get<> template function below (but GIL calls it at_c<>). This can be used for all types, but it requires compile-time knowledge of the index. There is another, more restrictive, concept for homogenous types only that also allows the brackets ([]) to be used. As a developer you decide whether your algorithm fundamentally requires a homogeneous type or not and you document/enforce this through the appropriate concepts, but if you can support the get<> syntax your algorithms that require points will be applicable to more types. I suspect that with a little cleverness most point operations can be done without array-style indices. For example; with the get<> syntax it easy to add a read-only homogenous coordinate without modifying the underlying point type: float get<3>(MyPnt2D&) {return 1;} float get<3>(MyVec2D&) {return 0;} //"Point at infinity" If you chose the [] operators I think you would have to tack an extra '1' to each object OR put some kind of 'if' statement that would be evaluated for each access to operator[]. 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. -- John