Re: [boost] Proposal/InterestCheck: Boost.Geom

Subject: Re: [boost] Proposal/InterestCheck: Boost.Geom
From: Anis Benyelloul (anis.benyelloul_at_[hidden])
Date: 2009-01-27 05:40:13

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,