Re: [boost] GTL compile time vs. run time accessors

From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 2008-05-03 08:32:18

Hello,

I haven't been able to participate to this already well advanced
discussion since I was off at the moment. If I summarize, I basically
agree with the conclusions given in the latest posts. I will only
quickly answer the questions asked me at the beginning.

>  >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.
>
>  In what way weaker?  This implies that there should be a type that can
>  provide compile time access, but can't meet the stronger requirement and
>  provide runtime access.  Can you produce such a type?

boost::tuple is such a type. The whole idea is that whenever runtime
access is available, compile-time access is easily providable, while
the inverse is not true (unless with series of if statements). So
compile-time requirements are easier to satisfy than runtime
requirements. This is what I have in mind when I say that compile-time
access is more "minimalistic" than runtime access. Keep in mind that
I'm really talking about the moment when the user has to provide a
compatible point from the data type he's working with. As said earlier
in this thread, he can still use his runtime accessors in his own
code.

>  >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.
>
>  Hmmm, that does inspire some thought, doesn't it?  At some point, though
>  the different coordinate types need to be used together and the result
>  will be auto-casting.  It seems reasonable to me to declare the
>  coordinate type of an object with heterogeneous coordinates as the one
>  to which the others will auto cast when used together.  Clearly, this
>  could be bad if you mix signed and unsigned, but that would end badly
>  eventually anyway.

I wasn't thinking about letting the compiler cast everything by
itself, but rather using precise type promotion rules when needed. But
it's just an idea for now, I have only noticed that some people do
require the ability to use heterogeneous data types.

Regards
Bruno