Simonson, Lucanus J wrote:
You will have to cast at some point to use the value, why is it more expensive to cast up front rather than at the last possible moment.
Steven Watanabe
This only applies to built in types. For user defined types, it may not be necessary to cast in order to operate on objects of two different types. ... Maybe I'm misunderstanding something, but it seems to me that an algorithm that works with Cartesian coordinates will tend to be very inefficient if it has to convert to and from polar coordinates on the fly at every access.
User defined mixed type arithmetic operators seems like a fairly unlikely circumstance. I'm not sure introducing complexity of keeping track of the different data types into the algorithms is warranted by such a use case. The interface is more likely to be used between modules rather than internally. For instance, imagine one legacy module operates on and produces its output in the form of polar coordinate points. A generic geometry library module consumes Cartesian coordinate points. Rather than iterate over polar points and convert them to Cartesian points that are fed into the generic library they can be converted on the fly through the generic interface. Rather than use the user point type for internal computation I use my own point type because I know it is fast. If the output of the Cartesian algorithm needs to be fed back into the polar coordinate module it can write out polar coordinates directly. The interface is providing the ability to refactor the application code and abstract away data type conversion. There are other good reasons not to require direct access to a data type's member data, most notable among them is that people typically don't provide such access in the public interfaces of their legacy classes because they learned in school that was a bad thing. For this reason, there has to be a temporary created by the generic interface and it might as well cast it to whatever global coordinate type the user deems best at that time. Luke