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

Subject: Re: [boost] Proposal/InterestCheck: Boost.Geom
From: Barend Gehrels (barend_at_[hidden])
Date: 2009-01-29 14:46:01

Simonson, Lucanus J wrote:
> 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...
>>     
True. I said somewhere else: "That is implemented through metafunctions 
somewhere else".  I  didn't explain because there are some options there:
- you can include a headerfile registering a c-array as a  point
- OR you can include a headerfile registering a c-array as a box (one of 
the two, there is a guard to avoid ambuigity).
- OR a segment
- alternatively you can implement manually traits classes to define that 
the c-array is like a point, or like a box, or a segment
- alternatively you can call a macro which is just a macro-shortcut for 
the traits classes. There are a couple of them, for 2D point, 3D point, 
box, ...

If the macro AND the header file are not provided you'll have to 
implement those traits classes of the fourth dash.
> 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?  
Sure, that is possible.

> 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.  
We left SFINAE, it worked but tag dispatching worked much better for us 
(thanks Dave!)
> 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 think we have about the same approach there.
> 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 s
>  ecretly 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.
>   
OK. But arrays are not that fine in a std::vector. We've also a lot of 
unit tests, but as soon as I want to test a line or polygon, I have to 
comment or erase the array-case. So it is fine for the examples, you can 
have points and boxes of them, but in many cases it is probably not that 
useful...
> 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.
>   
I explained that a bit above, but I can always copy and paste a snippet. 
Following is from the headerfile you can use to register (= specialize) 
a any-sized c-array as a point (2D 3D 4D etc). By the way, Luke, I 
appreciate all your comments and discussions on the list!

Here is the (Bruno's) snippet. I realize that this registers an 
any-sized c-array, for the example I originally wrote you'll have to 
(further) specialize [2] and [4] to a point and box

        namespace geometry { namespace traits {

                // specialize as being a POINT:

                template <typename T, size_t N> struct tag<T[N]> { typedef point_tag type; };

                template <typename T, size_t N> struct coordinate_type<T[N]> { typedef T type; };

                template <typename T, size_t N> struct dimension<T[N]>: boost::mpl::int_<N> {};

                template <typename T, size_t N>
                struct access<T[N]>
                {
                        template <size_t I> static inline T get(const T p[N]) { return p[I]; }
                        template <size_t I> static inline void set(T p[N], const T& value) { p[I] = value; }
                };

        }}

There is also a coordinate system (in a separate headerfile).

Regards, Barend