On Wed, Oct 8, 2008 at 2:53 PM, Michael Fawcett <michael.fawcett@gmail.com>wrote:
On Wed, Oct 8, 2008 at 5:33 PM, Patrick Mihelich <patrick.mihelich@gmail.com> wrote:
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 typedef geometry::point<float, 128> sift_descriptor; vs. typedef geometry::point< fusion::vector<float, float, float, float, ... /* 128 of these */> > sift_descriptor; which is probably beyond what Fusion supports, and would break the compiler anyway. For your use case, it would of course be possible to define your own heterogeneous point class. Now that I think about it, it could be very interesting to make the provided point classes Fusion-compatible sequence types via the extension mechanism. After all, we are already agreed on supporting compile-time access. And then, why not go all the way and write the default implementations of the core algorithms on top of Fusion? In that case typedef fusion::vector3<int, short, int> dem_point; would work out of the box. Patrick