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

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

Mathias Gaunard wrote:
> Barend Gehrels wrote:
> 
>> So this works as well:
>> int box[4] = {1,1,10,10};
>> int c[2] = {5, 5};
>> bool is_inside = geometry::within(c, box);
> 
> So an int[4] is a 2D box and an int[2] is a 2D point?
> That looks like quite some arbitrary choices...
> 
I agree, what about if an int[2] were also a 1D line segment?  I'd have to say that the geometric concept modeled by int[] is ambiguous.  Why not have int[4] be a quatrinary point?  Someone in a university somewhere will be annoyed by the arbitrary choice of making it a rectangle.  This is maybe a more obvious issue for me, since I have both an interval and point data types which are just class encapsulated arrays, but typesafe, so that you can't use an interval in an interface that accepts a point.  I also have an interval_concept and generic interfaces on interval in addition to those for point.  Finally, I have SFINAE protection on APIs that expect interval or point concept modeling objects.  I leave the choice of whether int[2] is a point or an interval up to the user to specialize the geometry_concept metafunction.  I use arrays all the time, especially in unit testing, because it is very concise to initialize them to constant values.  I also like to loop over them and secretly hope that vectorizing compilers will someday come along that can actaully optimize those loops.  Icc 11 is better than icc 10, but there is a long ways to go.

By the way, Barend, how do you accomplish distinguishing between int[4] and int[2] statically?  I'd like to see a code snippet to learn how that works.

Thanks,
Luke