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

[Yong Li]

Similar thing: doc->frame()->document().

The solution should be defining both const and non-const members:

const Frame* frame() const { reutrn m_frame; }
Frame* frame() { return m_frame; }

2011/6/2 Yong Li <yong.li.webkit at gmail.com>:
> I think we should add a rule like "a const member function should
> never return non-const pointer/reference".
>
> I have seen the problem in many places that you can get non-const
> reference on a const object.
>
> For example, InlineTextBox has
>
> InlineTextBox* prevTextBox() const;
> InlineTextBox* nextTextBox() const;
>
> Assume you have a function: void myFunction(const InlineTextBox* textBox)
>
> When the text box has a sibling, you can easily get a non-const
> pointer by calling textBox->nextTextBox()->prevTextBox(), which sounds
> ridiculous.
>
> 2011/5/31 Geoffrey Garen <ggaren at apple.com>:
>>>>> Even in a class that is used in a tree, I still think simple member variable accessor methods (that do not return tree neighbors)  should be const.
>>>>
>>>> OK. Why?
>>>
>>> Because it indicates to me and the compiler, that the method doesn't have side effects.
>>
>> A const member function can have side effects. It can modify any global state outside the object. It can also modify sub-objects inside the object, and return non-const references to sub-objects and related objects that might be used to produce side-effects at any time.
>>
>> It's exactly statements like this that make me think that const member functions are a bad idea -- people think they provide a guarantee, but they don't.
>>
>> Geoff
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>