Re: Implicit conversions for value subtyping
On Apr 19, 8:04 am, David Barrett-Lennard <davi...@iinet.net.au>
wrote:
Consider that we implement simple datatypes (i.e. simple "value
types") without virtual functions and all read only functions are
global functions (instead of class member functions). Let single
argument constructors be used to support implicit type conversions.
E.g. to emulate Square value is-a Rect value.
The following uses structs (public member variables) without
suggesting that is necessarily appropriate.
struct Square { int s; };
int side(Square sq) { return sq.s; }
struct Rect
{
Rect(Square s) : w(side(s)), h(side(s)) {}
int w, h;
};
int width(Rect r) { return r.w; }
int height(Rect r) { return r.h; }
int area(Rect r) { return width(r) * height(r); }
void Test()
{
Square s = {10};
int A = area(s);
}
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. 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".
It is simply entirely unnecessary to introduce such notions of
"inheritance" /at all/ in this case. Instead let's view Square
and Rect as distinct types in a multi-sorted algebra that just
happen to have coercion relations.
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? What about all the numerous
other types we made add in future, are we now talking about
multiple inheritance? Not anywhere close in my mind. How would
such "inheritance" thinking or terminology even be useful?
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.
the implementation of rectangle (i.e. the member variables).
In fact Square can be implemented in any way we like. E.g. by
recording the perimeter.
struct Square { int perim; };
int side(Square sq) { return sq.perim/4; }
Indeed that is one very nice result of increasing modularity
like this by using free functions heavily and /not/ trying to
force hierarchical notions such as "inheritance" onto the code.
Note that the implicit conversions are still available if the read
only functions use const references. E.g. area could be declared like
this
int area(const Rect& r)
{
return width(r) * height(r);
}
Questions:
1) Is this a reasonable technique?
Yes I think so. In my opinion this is /very/ reasonable and
"good". Unfortunately we are forced to make certain functions
(constructors, destructors, conversion operators, etc) member
functions. So there are inherent asymmetries in C++ that cannot
be avoided. In response we see idioms such as 'as<...>()',
'make<...>()', 'cast<...>()', etc have sprung to life (often
to support generic programming).
KHD
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]