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