On Thu, Oct 9, 2008 at 2:06 PM, Simonson, Lucanus J <lucanus.j.simonson@intel.com> wrote:
In VLSI layout we sometimes represent the layer as the z axis of a 3D coordinate system. Because there are only tens of layers we can use something smaller than int to store it. However, the compiler will often pad it back to word aligned addressing and insert padding bytes into a data structure, reducing the memory savings. Also, internally, all arithmetic is 32 bit or greater, so there is no advantage in using smaller data types for local operations. I think it is perfectly reasonable to allow point classes to have heterogeneous coordinate types, but require them to cast to and from a homogeneous coordinate type at the interface between that object and the geometry library. In all three examples, we would make the coordinate type of the interface between the point and the library int and allow the 16 bit value to cast up to 32 bits when it is read into an algorithm and back down to 16 bits when it is written out.
--Michael Fawcett wrote:
I don't understand why the interface or algorithm cares whether it's homogeneous or heterogeneous.
The interface or the algorithm must necessarily be much more complex to accommodate heterogeneous coordinates. Moreover, you have a real problem with casting when you do arithmetic between heterogeneous coordinates in an algorithm.
No, it's not necessary. Surely the interface is just taking a type that conforms to a concept, and both a homogeneous and heterogeneous point type will conform.
x_coordinate_type x; y_coordinate_type y; ?_coordinate_type result = x+y;
Boost.Typeof. Boost.Units also handles this gracefully, but I'm not sure how they ended up solving it. Regardless, this is not something the end-user cares how it works, just that it works. It's doable by the library writer, so should be done.
You would probably have to register a type for casting to:
x_coordinate_type x; y_coordinate_type y; general_coordinate_type result = (general_coordinate_type)x + (general_coordinate_type)y;
Which is exactly what you do if you cast to the general coordinate type in the interface between the algorithm and the data type.
This type of conversion is handled automatically by the compiler in much simpler expressions: short s = 10; int i = 10; int result = s + i; // no warning, no casting necessary It should be handled the same way (i.e. not at all) in the underlying algorithms. vec3<int, short, int> isi(80000, 1000, 80000); vec3<int> i(80000, 80000, 80000); vec3<int> result = isi + i; // no warning, no casting necessary --Michael Fawcett