Re: Implicit conversions for value subtyping
On Apr 22, 3:35 am, Keith H Duggar <dug...@alum.mit.edu> wrote:
On Apr 19, 8:04 am, David Barrett-Lennard <davi...@iinet.net.au>
wrote:
The width, height and area functions defined on rectangle values are
also available for square values, which is just what we need, and
could be viewed as a form of inheritance. By declaring these
functions inline a modern compiler will typically eliminate
temporaries and be as efficient as a specialisation for Square.
It's possible is /could/ be viewed as a "form" of inheritance,
but that would of course depend on how you define inheritance.
It certainly is not inheritance in the C++ definition.
Agreed
And no
matter what definition you choose, if it allowed this to be a
"form of inheritance" I would argue that said definition is at
total odds with any common sense meaning of "inheritance".
I was thinking of it as "inheritance" in the following sense: Let a
data type mean a set of abstract values plus operators on those values
(using operator in an algebraic sense). The "behaviour" of a datatype
is only externally visible through those operators. Relating this
back to C++ code, assuming all operators are expressed as free
functions without in-out parameters, an implicit conversion between
two datatypes means that all the operators of one are available to the
other - because of value substitutability. I think it is reasonable
to call that "inheritance" treating the word as simply meaning that
"stuff" associated with one "thing" is automatically available to
another "thing". Anyway that was the only point I wanted to make! I
just looked for synonyms of "inherit" at synonym.com and the only
alternatives it gave me are "get" and "acquire".
Suppose I create a coercion from complex<int,int> to rectangle,
does complex<int,int> now "inherit" from rectangle? What if we
add a coercion from rectangle to complex<int,int>, does rectangle
no circularly inherit from complex?
That's just weird so I'm not sure what your point is here. A better
example for me would be classes named Polar and Cartesian and we would
like implicit conversions in both directions. I haven't studied the
rules of implicit conversions for C++ to know whether such a thing
works in practise, but in principle I can't see any problems with
alternative representations of abstract values.
BTW the conversions between polar and cartesian representations
involve cos, sin, sqrt, atan2 which are inexact for rational numbers
(including floats). That could mean we have an example of the
following assertion breaking which I find extremely unappealing:
T1 x;
T2 y = x;
assert(x == y);
This can fail if coercions aren't invertible and y is coerced in order
to perform comparison using T1::operator==. On that basis I would
reject implicit conversions between polar and cartesian
representations.
I would hope that implicit conversions between datatypes satisfy
reasonable "laws" to make program correctness easy to reason about.
Unfortunately C++ doesn't give you a transitive closure of the
defined implicit conversions. Consider that we extend my previous
example with an additional type to represent an arbitrary
quadrilateral and we recognise that square value is-a rectangle value
is-a quadrilateral value. In addition, assume that we haven't defined
an area function specialised for squares or rectangles. Unfortunately
the following won't compile:
struct Quad
{
Quad(Rect r)
{
x[0] = width(r);
y[0] = 0;
x[1] = width(r);
y[1] = height(r);
x[2] = 0;
y[2] = height(r);
}
int x[3];
int y[3];
};
int area(Quad q)
{
return ( - q.x[0]*q.y[0] +
(q.x[0]-q.x[1])*(q.y[0]+q.y[1]) +
(q.x[1]-q.x[2])*(q.y[1]+q.y[2]) +
q.x[2]*q.y[2]
) / 2;
}
void Test()
{
Square s = {10};
int A = area(s); // error: no implicit conversion
}
In any case even a modern C++ compiler wouldn't optimise the code
adequately (and that's why "overrides" would be very useful even
though logically they are redundant).
I would expect that whenever there are cycles in the value
substitutability graph then in principle we would expect implicit
conversions to be available from any one to any other type in the
cycle. But that's going beyond C++ capabilities.
What about all the numerous
other types we made add in future, are we now talking about
multiple inheritance?
In the sense of inheritance I described above, definitely!
Related to this are union types which unfortunately aren't supported
adequately in C++.
Not anywhere close in my mind. How would
such "inheritance" thinking or terminology even be useful?
In the case of square value isa rectangle value, it is useful in the
sense that it is a reminder that one doesn't necessarily need to
implement operators on square that have already been written for
rectangles. If one forgets that then one may end up writing more code
than needed (and the C++ compiler won't complain of course).
Square inherits functions defined on rectangles but not
No it doesn't "inherit" the functions. Instead you have created
an algebra in which an implicit coercion makes syntax such as
width(square)
valid. Suppose I now declare and explicit function for square
int area ( Square s ) { return side(s) * side(s) ; }
would you now propose to say that I have "overridden the
inherited (from rectangle) area function"? That doesn't make
any bit of sense to me. "inheritance" has no place here.
I'm not sure why. I thought the "override" metaphor was quite a good
one. I would however say it's a very dangerous analogy because it
means something quite different to overrides of virtual methods in the
context of subclassing. However, on the other hand we are talking
about data types here and we know that subclassing is completely and
universally useless for data types so I would suggest that confusion
cannot occur for C++ programmers that properly understand datatypes.
I would say that such an "override" must not be allowed to change the
externally visible behaviour, but it can be useful to optimise
performance when the compiler is inadequate.
For any data types T1,T2 and unary operator foo I don't believe the
assertion below should be allowed to fail:
T1 x;
T2 y = x;
assert(foo(x) == foo(y));
"overrides" would need to respect that (for example).
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]