[webkit-dev] Do we have a style preference about const member functions?

James Robinson jamesr at google.com
Wed Jun 1 20:11:26 PDT 2011


On Tue, May 31, 2011 at 12:08 PM, Geoffrey Garen <ggaren at apple.com> 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
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110601/6dc0ed8c/attachment.html>


More information about the webkit-dev mailing list