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:
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
> I have read your documentation briefly and looked at your point.hpp and
> point_traits.hpp as well as several other files.
> 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.
> 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
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
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,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk