On May 31, 2011, at 12:08 PM, Geoffrey Garen wrote: >> I agree that const should be used for "logical constness". The rule should >> not be merely "doesn't alter any data members of this object" but rather >> "does not alter observable state of this object or vend any type of pointer >> or reference by which observable state of this object could be altered". >> >> Precisely! > > I like this explanation too. > > I'm trying to think of a simple way to explain / test whether something falls > into the category of logical constness, since it can be ambiguous. > > It occurred to me that a simple, though imperfect, test is just, "Is this > function called by an owner of a const pointer / reference?" After all, a > const member function is meaningless if nobody points to the class through a > const pointer / reference. For classes like DOM and render tree nodes, which > have no meaningful const-pointer-owning clients, the answer is always no. For > other classes, the answer is yes, but only if someone has found a meaningful > use for a const pointer or reference to the class. > > So, perhaps the real style question we should answer is when to use const > pointers / references, since the answer to when to use const member functions > will follow from it. > > What are some good examples of existing code that meaningfully uses a const > pointer or reference? (Something other than, say, the obligatory const& in a > copy constructor.)
I agree that one useful distinction is whether a particular kind of object is every manipulated via const pointers or references. If we never use const references/pointers to a particular kind of object, then it is probably not useful to maintain const-correctness discipline for that class. If we wanted to make the DOM or render tree thoroughly const-correct, the key question would be what client code would access via const pointers or references. For container classes, it is almost certain that some client will wish to vend or consume const references, even if the very first client doesn't. There's probably other classes where it's less clear-cut. Regards, Maciej
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
