Printable View
Why can't I inherit a class as mutable? In other words, I'd like all methods of a base-class to be implicitly mutable:
Do any compilers do this? Why isn't it a standard feature?Code:class A
{
int foo();
}
class B: public mutable A
{
B(){}
int bar();
}
int main(...)
{
const B* b = new B();
B->foo(); // Allowed because B inherits a mutable A.
}
Can anyone suggest the best work-around?
Mine doesn't, at least from memory it doesn't. I use Microsoft Visual C++ 2008 Express Edition. Just create an instance of A and call foo() from it. By the way, one quick question, can you call a non-const function with a const object?
If I'm not mistaken, it's always members that are mutable, not *this itself.
As to a solution, the classes are not const-correct, so there's no point in trying to declare the pointer const - it gives no guarantees if you are looking for ways to get round const-correctness at the same time. (As they say, const is a "virus", it needs to propagate to all parts of the code if you want to use it properly. You can't make some parts of the code const-correct and other parts not.)
Or, instead of inheriting, make A a mutable member of B (but again, there should be some justification for that).
No! That's the whole point of using const (but you can do the converse).Quote:
By the way, one quick question, can you call a non-const function with a const object?
The point about mutable is that it allows innocuous changes to be made to objects which are otherwise const. Of course, it's debatable what is innocuous at design time, but at compile time it's defined. So a const pointer does give a guarantee: that members not declared mutable won't be changed.Quote:
As to a solution, the classes are not const-correct, so there's no point in trying to declare the pointer const - it gives no guarantees if you are looking for ways to get round const-correctness at the same time. (As they say, const is a "virus", it needs to propagate to all parts of the code if you want to use it properly. You can't make some parts of the code const-correct and other parts not.)
I also don't accept the implication that this is in some way dangerous. Sometimes the alternative is that you have to declare methods as not const which conceptually are. Then you have to pass around non-const pointers where you'd prefer to pass const. Then the system really does break down. A little defined, thought-out mutability is far preferable.
Yes, I agree on both counts. I assume by 'justification' you mean something more conceptual than just my search for const-safety? It's someone else's code which I'm relunctant to tamper with but I think they were probably right to use inheritance - hence my wish to *inherit* mutably.Quote:
Or, instead of inheriting, make A a mutable member of B (but again, there should be some justification for that).
Maybe I'm confused (okay, that's probably a certainty), but why should a const B have a huge non-constant portion? There's probably a good reason for that, but I can't seem to come up with a situation where that makes sense.
(One possible workaround that I haven't tried: if you make whichever of your A members mutable, is that inherited in B? If so, then perhaps you can set it there.)
From what I see, when you say "inherit a class as mutable", you mean to inherit a class such that all the member functions of the base class are somehow declared const, and all the member variables of the base class are somehow declared mutable.Quote:
Originally Posted by major_tom3
Why should it be a standard feature? Consider a variant of your example:Quote:
Originally Posted by major_tom3
If it is allowed, it becomes a case where just looking at p->foo(), and knowing that p is a pointer to A, we cannot determine if the call is allowed or not allowed without knowing the actual type of the object that p points to at run time. If it is not allowed, then this feature breaks Liskov substitution, since replacing the const pointer to the base class with a const pointer to the derived class causes the code to behave differently.Code:int main()
{
const A* p = new B;
p->foo(); // Allowed or not allowed?
delete p;
}
Or you can use const_cast<>. *evil grin*Quote:
Sometimes the alternative is that you have to declare methods as not const which conceptually are. Then you have to pass around non-const pointers where you'd prefer to pass const. Then the system really does break down. A little defined, thought-out mutability is far preferable.
To the OP: maybe you can explain what you're trying to do, exactly what the base and derived classes are, etc. That's probably the only way you'll get a viable solution suggested . . . .
On a conceptual level, const member functions say, "I'm not going to modify the logical state of this object." The key word here is "logical" - if a class has a function getInformation() and this information is retrieved via, say, a database query, that class might want to cache this information locally so that it doesn't have to repeat the query all the time. But this cache is not part of the logical state. The logical state is observed through the return value of getInformation(), and assuming a proper cache invalidation mechanism, that return value is the same whether the query is executed or the cached value is returned.
So that's why we have mutable: to allow modification of members that are not part of the logical state in const member functions.
That's fine for members. But public base classes are more than that. It makes sense to have a member and say, "But this member isn't part of the logical state." The same thing doesn't make sense for a base class. That base class better be part of the logical state, or it has no business being a base class. At least, I can't think of any conceptual view of inheritance where it would make sense.