Re: [boost] Geometry Template Library from Intel

From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 2008-05-02 04:36:05

>  >In the second preview of the library, there was also runtime indexing
>  >accessors, but they should disappear to only have compile-time
>  >accessors as shown above (I'm currently working on this with Barend).
>
>  There is no need to have both run time and compile time accessors, and
>  you can do things with run time accessors that you cannot do with
>  compile time accessors.  The reverse is not true.  I think you made the
>  wrong decision and should consider making the accessors runtime only
>  instead.

I precise that it's not a final decision, just an idea. But my guts
feeling is that compile-time access is a weaker requirement than
runtime access, so in the idea that a concept must always model the
*minimal* requirements, compile-time should be preferred.

>  Consider the difference between:
>
>  int get(array<int, 2> point, int index) { return point[index]; }
>
>  and
>
>  int get(const tuple<int, int>& point, int index) {
>         if(index==0) return get<0>(point); else return get<1>(point); }

The latter look very ugly indeed, and it's precisely why I prefer
compile-time access. Here are the same example with compile-time
access:

template <int I>
int get(array<int, 2> point) { return point[I]; }

and

template <int I>
int get(const tuple<int, int>& point) { return point.get<I>(); }

This time, we access both structures as easily. Just because arrays
and tuples are both accessible with a compile-time index, while tuples
are not accessible with a runtime index. Adapting a struct { x, y, z }
would be trickier in both cases, but looks more natural with
compile-time indexes in my opinion (you map a compile-time stuff onto
another compile-time stuff).

As pointed out by John, another advantage of compile-time access is
the ability to have different types for each coordinate. It's
something that has been asked for several times during recent
discussions on this list. I was even wondering the other day if it
wouldn't be better to not require any coordinate_type typedef and have
the algorithms deducing by themselves the type of each coordinate by a
BOOST_TYPEOF on the accessor.

For me, the only advantage of runtime access is to be easier to use
inside the library algorithms. As the writer of a library is not here
to facilitate his own life but the user's life, this kind of advantage
shouldn't be taken into account if it's the only one.

This being said, if you have a precise example of algorithm that
technically needs runtime indexing on points, could you please show it
to me? I haven't been able to think of such a situation until now. If
every algorithm of the library is able to work on compile-time
indexes, so I definitely don't see why it would require runtime
access. It would mean requiring more than actually needed, which is a
no-sense for a concept.

Regards
Bruno