Boost logo

Boost :

Subject: Re: [boost] Proposal/InterestCheck: Boost.Geom
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-01-26 13:49:48


Anis Benyelloul wrote:
> Boost.Geom purpose is to provide a unified, zero-cost and pretty
> interface around existing geometric primitive implementations (for
> now only points and rectangles in 2D and 3D).

I gather that by pretty you mean . operator syntax for calling member functions of objects? For what it's worth I agree with you that dot operator syntax is prettier, but there are some drawbacks to the use of member vs. nonmember implementations.

I have read your documentation briefly and looked at your point.hpp and point_traits.hpp as well as several other files. I work in the VSLI CAD and VSLI manufacturing process modeling application domains. In my domain practically every object is a rectangle, we work with points extensively, and object work with rectilinear polygons. For me the data I work on is very similar to your GUI rectangles and points, except rather than manipulating handfuls of rectangles I have billions of them. Aside from that, the rationale you describe for your library is exactly the same as my own rationale for my generic geometry library. Your approach is also very similar to my original approach. The problem I wanted to solve is that rather than GUI frameworks we have CAD tool frameworks that define their own rectangles, points, polygons etc. and code written for one is not portable to another. I solved that, then I solved it again, and again, and again. Now Dave has suggested an even nicer solution still, and I'll probably solve it yet again before boostcon. Barend is also on his third or fourth iteration with his geometry library.

> I have uploaded the code+doc+tests in geom-0.1.zip in the vault.

There is a Math-Geometry directory in the vault where you will find quite a few similar submissions, including my original submission, gtl. You might want to consider moving yours to make it easier to find.

> geom::point<QPoint> pt; // A QPoint instance behind a geom::point
> interface geom::box<QRect> rc; // A QRect instance behind a geom::box
> interface

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? You seem to have in mind that people should unwrap an object in this manner. Do you also intend people to wrap a point_type by casting it to point<point_type>?

I find your point_impl abstrction rather confusing. It seems like you are allowing a point<point<point_type> > with this construct. 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, with all supported operations on point<> being defined as a trait, why not just require that the user specialize point<> itself and provide a default that expects them to conform to some interface?

In any case, I suggest you look at my library in the vault, Barend's library, Brandon's library, and my library in the sandbox (which is a rewrite of my original vault submission.) You will be able to find all of these by reading the boost dev. list archive searching for "geom". I think you will find we all solve the same problem at the "lowest level", but Barend, Brandon and myself also provide quite a bit of algorithmic meat on the bones of the generic interfaces to geometry objects. I hope you enjoy reading the past discussions from the boost dev list archives. I know that finding people who are intersed in solving the same types of problems I am working on has been a positive experience for me.

Regards,
Luke


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk