Hello Barend, I decided to remove boost::geometry from the implementation of my Vector/Point classes and instead focus on how to tell boost::geometry how to use my classes. I've been using CGAL for a few years, so I'm "baby-duck" imprinted on that design. I also used CGAL for affine transforms and some spherical conversions, so I hope to try boost::geometry for that functionality as well. I really had a hard time understanding what a "geometry" was. I expected a "geometry" to be a "system", rather than an object. I also expected "points" to be referenced to a "reference frame" so that points that have difference reference frames cannot operate on one another without going through a transformation. Much as in std::chrono, time_points from different clocks cannot be operated on together. But durations, the difference of two time_points, are interoperable. CGAL was also very difficult for me to learn because they use the concept of a "kernel". Perhaps I'm not not geometry savvy, but I feel a need for a geometry library for dummies. It seems a shame to keep coding "point/vector" over and over. It reminds me of when I used to write linked-list-queues in C from scratch on every project... I really missed going to BoostCon this year. I hope you all had fun! Thanks for all the hard work! terry ----- Original Message ----- From: "barend" <barend@geodan.nl> Newsgroups: gmane.comp.lib.boost.devel To: <boost@lists.boost.org> Sent: Wednesday, May 19, 2010 3:40 PM Subject: Re: [geometry][units] Vector Class
Hi Terry,
Op 19-5-2010 14:29, Terry Golubiewski schreef:
I imagine that using geometry/unit together will be common. I just posted these files on boost-user too, but I wanted the geometry/units developers to see what I've done. I think it was too difficult to make a Vector<quantity<U,T>> class.
Agreed.
However, it could be done, so that is very good!
The bad news is: the cartesian_distance class will go away. One of the reasons is the one you showed in your attachment -- you actually have to reimplement the whole strategy including return type. The good news is that it will be simpler to implement, and actually the distance will have the same measure as the coordinate system, so meters -> coordinate system: meters -> distance: meters, no T*T vs sqrt(T) (or handled internally).
The problem is that the geometry library assumes that the types of T*T and sqrt(T) is the same as T.
Sure. During BoostCon I presented this "convertible to double" approach (which is cartesian_distance) and Eric remarked that it might give problems, using the return type in meta-programming, and indeed it does. Thanks for your efforts and sorry about the change needed in the near future, but I hope it will be simpler indeed. I'm still not sure about it anyway, the review report tells us to show how units can be integrated and I envisioned it being in the coordinate system, not in the point type. So I'll look more close into your implementation. Note also that a "vector" is actually not part of Boost.Geometry but we hope that it can live apart from it, e.g. as Emil's vector/matrix library, and work together (though there is currently some vector arithmetic present).
Regards, Barend
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost