On Tue, May 31, 2011 at 12:08 PM, Geoffrey Garen <[email protected]> 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 personally find that in a number of render tree functions declared to take a const RenderObject* that the const-ness is a useful hint that the function will not be manipulating the object in unexpected ways. Examples: http://codesearch.google.com/codesearch?hl=en&vert=chromium&lr=&q=%22const+RenderObject%22+file%3AWebCore&sbtn=Search (click "Next" at the bottom to see more results). My understanding is that these functions could not take a const RenderObject* parameter if RenderObject did not supply a set of const simple accessors and utility functions. We could convert RenderObject over to have no const member functions and convert all of these utility functions to take RenderObject* parameters instead, but I think that would lose some of the intent of the code. I'm curious if there was a specific patch or piece of code that lead you to send this email out - perhaps we make a better decision about whether to change our approach with more concrete examples of problems the current situation has caused or is causing. - James > > Geoff > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
