On 29/09/11 8:13 AM, Marco Leise wrote:
Am 26.09.2011, 18:12 Uhr, schrieb Jonathan M Davis <jmdavisp...@gmx.com>:
On Monday, September 26, 2011 08:01:29 Steven Schveighoffer wrote:
For example, storing a reference to a mutex in an object, or a reference
to an owner object. It's the difference between a "has a" relationship
and a "points to" relationship.
Your lazy loading idea does not help at all for these.
I believe that the two main complaints about the lack of logical const
which
have been coming up in the newsgroup have been the inability to cache the
return values of member functions and the inability to lazily load the
values of member variables.
I brought the issue with "points to" relationships up in another thread
here - also about transitive const. I believe a proper object-oriented
design should allow for pointers to other objects that have nothing in
common with the host object. car.getVendor() for example should always
return the mutable instance of the shop where that - possibly const car
- was bought. Let's call it the "parent reference" issue for short :)
+1 to Steven's comment.
Why would a car be able mutate it's vendor?
Also, the problem with mutable parent references is that it completely
defeats the purpose of const. Consider this C++ code:
struct Tree
{
Tree* m_parent;
std::vector<Tree> m_children;
void doSomethingConst() const;
};
The tree owns it's children, and has a mutable reference back to its parent.
Inside doSomethingConst, I shouldn't be able to modify my children
because I own them, however, you are arguing that I should be able to
get a mutable reference to my parent. However, if I can get a mutable
reference to my parent, then I can get mutable references to its
children, of which (this) is one. So, through my parent I can get a
mutable reference to myself, circumventing the const, making it pointless.
Strict transitive const is essential. Without it, it becomes far too
easily to wriggle your way out of const, which breaks the guarantees of
immutable.
