From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 2008-05-03 08:32:18
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
> >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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk