Simonson, Lucanus J <lucanus.j.simonson <at> intel.com> writes:
I gather that by pretty you mean . operator syntax for calling member functions of objects?
By ``pretty'' I mean these kind of things: box<..> bx; bx.center() = point(0,0); // this will ``move'' the box so that it's center is // at the origin bx.corner<xmin, ymin, zmin>()=bx.center() // this will stretch the box so that // the corner is where the center was before In other words, the interface allows more complicated operations then simple access to the members. Instead of ``pretty' you could say ``rich'' or ``richer than a strcut point {int x,y;};''
I have read your documentation briefly and looked at your point.hpp and point_traits.hpp as well as several other files.
Thanks.
We have CAD tool frameworks that define their own rectangles, points, polygons etc. and code written for one is not portable to another.
Exactly. So I'm not alone, glad to hear it :)
You might want to consider moving yours to make it easier to find. Done.
Your template point<> has a private member variable m_impl of point type T and allows the user to get a reference to that member by calling impl(). Why then make m_impl private?
Well, this is just to maintain the ``all public members are methods''-consistency thing. But you could make it public.
You seem to have in mind that people should unwrap an object in this manner.
Yes, this is very important when the time comes to pass your object as a parameter to the underlying framework.
Do you also intend people to wrap a point_type by casting it to point<point_type>?
Yes. There is a geom::point_wrap() and a geom::box_wrap() non-member functions that do that. Maybe I should mention them earlier in the manual.
It seems like you are allowing a point<point<point_type> > with this construct.
Yes, this not explained until somewhere deep inside chapter 5 or so. But this is not very important from a user perspective. This mainly allows to cut down the number of necessary member overloads of geom::point<>.
I don't think it is neccesary for it to be a friend of point<>, because you can simply call the public impl() function of point<>.
Your traits seem a little heavy,
Yes, but it is necessary to allow type-specific optimizations (such as if you are packing the X and Y coordinates in the same machine word, geom::point<>::operator==() will be able to compare both coordinates with the same operation, instead of the generic x1==x2 && y1==y2). On the other hand if you don't want to specialize everything (and are happy with the generic implementations) you can use point_xy_trait/point_xyz_traits which will specialize point_traits for you based on a subset of its features.
In any case, I suggest you look at my library in the vault,
Sure! Reguards,