Hi,
Cool, compile time indexing is very useful. But, I'm not sure I see the need for using tuples. I can't offhand think of a use case where the dimensions are of heterogeneous type, so wouldn't a simple array work?
Sure a simple array should work. The point of a generic library is that a simple array would work, so would a tuple, and so would your custom point class.
As for the heterogeneous types, think of huge (GBs worth) digital elevation models in meter units where altitude is in a range from 0 - 20,000m. In that case, my point type would be something like vector3<int, short, int> instead of a vector3<int>.
With a 1024x1024 file, that would result in a savings of only 2MB of memory, but extrapolate that out to a 16384x16384 file, and the savings is 500MB.
OK, yes, I'm convinced. Support for heterogeneous types has its uses. But I will still ask, why use a tuple to store the data in the basic (Cartesian) point class? Barend and Bruno's library uses an array instead, which I think should be preferred for two reasons. (1) I would still think the homogeneous case to be much more common the heterogeneous case. (2) Using a tuple makes it difficult or impossible to use the generic point class in high dimensions. Consider
Stop me if I'm wrong but what you're discussing now is how to implement the point class provided by an ideal geometry library, right? If so, I think it's not the most important concern since, as I've already said, the primary goal is not to provide a point class but to define how points are accessed and defined in general. I think that, by talking about tuples, Brandon was rather pointing out that points should be accessible the same way as tuples: get<N>(p). Which is quite a general consensus now, IMO. Bruno