Re: Implicit conversions for value subtyping
On Apr 19, 3:04 pm, 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; }
You pass Square by value, and that is bad idea when Square represents
something with enough properties (that even squares have like
location, color, inclination degree ... etc.) to pass it by reference.
Better is:
int side(Square const& sq) { return sq.s; }
struct Rect
{
Rect(Square s) : w(side(s)), h(side(s)) {}
This causes often secret overhead, you may get conversion copy where
you did not expect it. I usually put explicit in front of it.
Again ... it goes by value.
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); }
Again pass by value.
void Test()
{
Square s = {10};
int A = area(s);
}
If you did not make Rect constructor explicit then it works. Otherwise
you have to write:
int A = area(Rect(s));
That indicates to possible reader that conversion takes place. So if
they want to optimize (and graphics people often do) then they write:
inline int width(Square const& sq) { return side(sq); }
inline int height(Square const& sq) { return side(sq); }
inline int area(Square const& sq) { return
width(sq)*height(sq); }
As results most compilers generate equivalent of:
int A = 100;
Or, if A is not further used, (like in your case) with nothing.
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.
Square inherits functions defined on rectangles but not 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; }
That works fine, with same remarks about pass by value.
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?
I avoid it. In large project such implicit conversions cause sometimes
hard to discover bugs because they hide simple typos.
2) Is there a reason why C++ was designed so that const member
functions defeat the implicit conversions on *this?
I don't think that they do. I think that your own const-correctness
and pass-by-value defects defeat it. Try if it works:
struct Square { int s; int foo() const; };
int side(Square const& sq) { return sq.s; }
struct Rect
{
Rect(Square const& s) : w(side(s)), h(side(s)) {}
int w, h;
};
int width(Rect const& r) { return r.w; }
int height(Rect const& r) { return r.h; }
int area(Rect const& r) { return width(r) * height(r); }
int Square::foo() const { return area(*this); }
void Test()
{
Square s = {10};
int A = area(s);
int F = s.foo();
}
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]