What does it mean:
Basically, what inheritance means is: I want my class to have a hidden
object field of type A, and that syntactically, every attempt to
access a member that is not in B will be redirected to a field of the
hidden object. There is one problem here, the hidden object field
cannot be constant. Constant inheritance should enable us to do that.
In the case of constant inheritance, the compiler will try to redirect
the member access only if it is a member access that does not violate
the constness of the hidden object field (i.e. not allowed to access
non-const methods, not allowed to change variables that aren't mutable
except for through the constructor of A). In case the constness of the
hidden object is violated, the compiler will emit a proper error
message.
A practical use case that required this (simplified):
Assume we have the following class:
struct Rect
{
int width, height;
int left, top;
}
Indeed, somebody messed up, and the class Rect contains public fields.
However, now is it is too late (it could also be because I'm using
something that was defined in old C code). Anyhow, I would like to
define a class which inherits from Rect and represents a Square (Thus,
I add the requirement that height == width, while wanting to preserve
the original Rect interface as much as possible). A complicated
solution would be to somehow inherit from Rect and add this
requirement, but I feel this is too specific. A more general solution
(but less good) would be to limit myself to working with an immutable
square class (in my case it was enough as there were few changes which
were done via copy constructors), this looks as follows:
class ImmutableSquare : public const Rect
{
private:
Rect ConstructRect(int left, int top, int size)
{
Rect r;
r.left = left; r.top = top; r.width = r.height = size;
return r;
}
public:
ImmutableSquare(int left, int top, int size) :
Rect((ConstructRect(left, top, size))
{}
}
This class gives me Square objects with a Rect interface.
Interesting theoretical view point:
We look at the following two definitions:
class A {...}
typedef const A B;
While the first definition defines a class, the second one defines a
type. In fact, we can look at what I offer here as a new view of
constness, as something that creates a new class from an existing one.
One can think of "const A" as a new class, which inherits (privately,
not public/protected) from the class A, and blocks constness-breaking
member access for anyone
except it's constructor. One can argue regarding how this interacts
with abstractness, but I feel it would be the simplest to say that if
A is abstract, then so is const A, and the only way to get rid of this
abstractness is to implement the abstract methods. A tricky point
would be abstract methods which violate constness, and I feel the way
it should be handled is not to allow inheriting from a const class
which contains abstract constness-breaking methods.
Questions;
Is it possible to have a class which inherits both from A and const A,
if so, how do we differentiate between members? B::const A::x doesn't
look so well.
Is it possible to somehow extend this to new kinds of inheritance
which are based on other field properties? static? volatile? thread-
local (in case the standard adds it)?
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]